Filsystemet — hva som ligger hvor

På Windows får hver stasjon en bokstav. Systemet ligger på C:, dataene dine på D:, og USB-pinnen tar bokstaven som tilfeldigvis er ledig. Linux kaster alt det der. Det finnes ett tre, det starter på /, og alt annet blir podet inn i det et sted: en ekstra disk, en USB-pinne, en nettverksdeling. Ingen stasjonsbokstaver, bare steder.

Stedene har navn som ser kryptiske ut først. /etc, /usr, /var, /proc. Hvert av dem har en jobb, og jobbene endrer seg knapt mellom distribusjonene. Kapittelet Filnavigering lærte deg å flytte deg rundt (pwd, cd, ls); denne siden handler om målene, og hvorfor du skulle se inn der.

Alt her er sjekket på Ubuntu 26.04, Fedora 44 og Arch. Der de tre er uenige, sier teksten fra om det.

Her er treet i ett bilde:

/                        the root of everything
├── home/                one folder per ordinary user
├── root/                home of the root (admin) user
├── etc/                 system-wide settings, plain text
├── usr/                 installed software
│   ├── bin/             programs from distro packages
│   ├── local/           what you install yourself
│   └── share/doc/       documentation shipped with packages
├── var/                 data that changes while the system runs
│   └── log/             logs, including the systemd journal
├── tmp/                 scratch space, disposable
├── opt/                 add-on software bundles
├── srv/                 data served to the network
├── boot/                kernel and bootloader files
├── dev/                 devices as files
├── proc/                live process view from the kernel
├── sys/                 live hardware view from the kernel
├── run/                 runtime state, cleared at boot
├── mnt/                 for filesystems you mount by hand
└── media/               removable drives (desktop convention)

Et ekte system har noen flere oppføringer på øverste nivå (et par bibliotekmapper å begynne med), men det er kartet. Den faktiske utlisten fra Ubuntu-containeren, ett navn per linje:

$ ls /
bin
boot
dev
etc
home
lib
lib64
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var

Fedora legger til én eneste oppføring, afs. Den er ikke en del av standardoppsettet, og den står ikke i FHS-spesifikasjonen som det lenkes til på slutten av denne siden. Akkurat dette imaget kommer bare med den. En standard Ubuntu-skrivebordsinstallasjon har én til: /snap — samme ide som /opt, samlet programvare i én mappe. Arch-containeren mangler media og har to løse filer liggende øverst, pkglist.x86_64.txt og version, rester etter imagebygget. Det er støy på overflaten. Under er oppsettet det samme.

Hjemmebanen din: /home og /root

/home er der vanlige brukeres filer bor, én mappe per innlogging. Heter brukernavnet ditt mira, ligger filene dine i /home/mira, og innholdet kan du organisere akkurat slik du vil.

Skallet har en snarvei for det: tilde-tegnet, ~, betyr alltid din egen hjemmemappe. En cd uten argumenter tar deg også dit, fra hvor som helst i treet.

Én vane verdt å ta tidlig: ren ls gjemmer alle navn som starter med et punktum. Kjør ls -a i hjemmemappen din, så dukker det opp en annen befolkning. Filer som .bashrc er innstillinger per program, én fil per verktøy, og senere i denne guiden får én av dem en hovedrolle.

Root-brukeren bor ikke i etasjen under sammen med alle andre. Administratorens hjemmemappe er /root, helt oppe på toppen av treet, adskilt fra /home. Innholdet er det distribusjonen har lagt der: på Arch-containeren gir ls -a /root deg .bash_history, .config og .ssh, og ingen .bashrc i det hele tatt. Ikke regn med at én bestemt skjult fil finnes, selv for root.

Innstillingsetasjen: /etc

Der de skjulte filene dine holder innstillinger for én bruker, holder /etc innstillinger for hele maskinen, i ren tekst du kan lese med ingenting mer avansert enn cat.

Distribusjonen legger igjen ID-kortet sitt her. /etc/os-release sier hva du kjører, og de tre testcontainerne oppgir, henholdsvis:

PRETTY_NAME="Ubuntu 26.04 LTS"
PRETTY_NAME="Fedora Linux 44 (Container Image)"
PRETTY_NAME="Arch Linux"

(Fedora-strengen sier Container Image fordi det er varianten som er testet. En Fedora-arbeidsstasjon formulerer det annerledes.)

/etc er også der hver pakkebehandler oppbevarer instruksjonene sine, og stiene varierer etter familie. Ser du én av dem, vet du i ett øyeblikk hva du sitter på:

• Ubuntu og Debian: /etc/apt/sources.list.d
• Fedora: /etc/dnf og /etc/yum.repos.d
• Arch: /etc/pacman.conf

Ikke anta likevel at én bestemt fil garantert finnes her. /etc/hostname finnes på Ubuntu-containeren og mangler på Fedora- og Arch-containerne. Det som havner i /etc, avhenger av installasjonen.

Programmene: /usr, /bin og /usr/local

/usr er der programvaren bor. Programmer fra distribusjonspakker havner i /usr/bin (ls, bash og venner), mens /usr/local/bin er din: skript du skriver, programmer du kompilerer, verktøy installert utenfor pakkesystemet. Det er det avtalte stedet for selvinstallert programvare.

/opt er reservert for den andre typen selvinstallert programvare: en hel tredjepartsbunt i én selvforsynt mappe, som /opt/foo, i stedet for enkeltfiler samlet under /usr/local.

Dette forklarer i ettertid en linje fra guiden systemd-timere, hvis eksempeltjeneste kjørte ExecStart=/usr/local/bin/foo.sh. Skriptet lå der fordi det er der et slikt skript hører hjemme.

To utskrifter verdt et nærmere blikk:

$ ls -ld /bin /tmp
lrwxrwxrwx+  1 root root   7 Apr 20 08:46 /bin -> usr/bin
drwxrwxrwt+  9 root root 180 Sep  2 19:21 /tmp

Den første linjen sier at /bin ikke lenger er en ekte mappe. l-en først i rettighetsstrengen markerer en symlenke, og pilen viser målet: /bin er et annet navn på usr/bin. Dette er merged-usr-oppsettet. Distribusjonene har brettet den historiske /bin inn i /usr/bin og lar symlenken ligge igjen. Dermed er et program nådd via /bin/ls og ett nådd via /usr/bin/ls samme fil, og alle gamle skript som hardkoder /bin fortsetter å virke. (Symbolet bakerst på den linjen varierer: Fedoras ender med et punktum, Archs med ingenting — +-en du ser på denne maskinen markerer en tilgangsliste, ekstra regler lagt oppå grunnmodusene. Datoen er bare når imaget ble bygget. Pilen er det som teller.)

Det er en liten vri til i samme slekt. På Ubuntu er /sbin en symlenke til usr/sbin, og /usr/sbin er en ekte mappe. På Fedora går begge navnene via /usr/sbin: /sbin peker på usr/sbin, og /usr/sbin peker på bare bin, altså /usr/bin. På Arch er det kortere: både /sbin og /usr/sbin peker rett på usr/bin. Ha det i bakhodet til avslutningen nedenfor, der det forklarer en overraskelse.

Én du blir glad for finnes: /usr/share/doc, haugen med dokumentasjonsfiler som kom med pakkene dine.

Det som endres: /var og /tmp

/var holder data som endres mens systemet kjører, i motsetning til programmer, som stort sett sitter i ro. Det mest besøkte hjørnet er /var/log, der loggene hopes opp; systemd-journalen har filene sine i /var/log/journal. Kapittelet Tjenester og logger handler helt og holdent om å lese dem.

/tmp er mellomlager, og den andre linjen i utskriften over forklarer personligheten dens: drwxrwxrwt. t-en på slutten er sticky bit, det som hindrer en mappe alle kan skrive i fra å ende i fullt kaos; kapittelet Rettigheter og eierskap tar rettighetsstrengen fra hverandre ordentlig.

På alle tre testmaskinene er /tmp en tmpfs: den bor i minnet i stedet for på disken, og innholdet overlever ikke en omstart. Det er konfigurasjonen til disse tre, og den varierer med distribusjon og oppsett. Andre installasjoner kan ha /tmp som en helt vanlig mappe på disken. Uansett er den praktiske regelen den samme: regn med at /tmp kan tømmes når som helst. Legg aldri noe der inne som du ville savnet.

Der kjernen later som: /proc, /sys og /dev

Tre av mappene helt øverst er ikke egentlige filer på disken i det hele tatt. Kjernen finner dem opp mens du ser på.

/proc er kjernens vindu mot kjørende prosesser, og de numeriske undermappene er oppkalt etter prosess-ID-er. Hver av dem tilhører den kjørende prosessen med den PID-en. Du kan sjekke det selv: kjør ps aux, plukk en PID fra venstre kolonne, så har /proc en mappe med det tallet. Skallet ditt og ps-kommandoen selv får også PID-mapper.

Filene i /proc kommer med én advarsel: ikke stol på størrelseskolonnen.

$ ls -l /proc/uptime
-r--r--r-- 1 nobody nogroup 21 Sep  2  2026 /proc/uptime

Den filen hevder å være 21 byte. Noen av naboene oppgir 0, andre oppgir tusenvis. På dagens kjerner er størrelsene i /proc og /sys en blandet sak, så les kolonnen som pynt. (nobody nogroup-eieren er en bivirkning av containerens brukermapping, ikke noe du ville sett på en vanlig installasjon.)

/sys kjører det samme trikset for maskinvare: en visning i sanntid av enhetene og driverne kjernen kjenner til. Den samme advarselen om størrelser gjelder.

/dev er der enheter blir til filer. Den mest kjente beboeren er /dev/null, vist av ls -l som crw-rw-rw-, der c-en først markerer en tegnenhet. Alt som sendes til /dev/null forsvinner uten spor, noe som har gjort den til den offisielle søppelplassen for uønsket utdata. Skript skriver dit med vilje når de vil ha støyen fra en kommando borte.

Monteringspunkter og resten: /mnt, /media, /run, /boot

Noen få mapper finnes stort sett bare for å være monteringspunkter, steder der andre filsystemer festes til treet.

/mnt er det tradisjonelle stedet for noe du monterer selv, for hånd. /media er skrivebordskonvensjonen: på en maskin med grafisk sesjon blir flyttbare stasjoner montert under den. En maskin uten skjerm kan mangle mappen i det hele tatt; på Arch-testcontaineren finnes ikke /media, rett og slett.

/run er der det kjørende systemet oppbevarer tilstanden sin. Den er en tmpfs som tømmes ved oppstart, så alt som ligger der, ble lagt der i denne oppstarten og gjelder bare den.

/boot holder filene en maskin trenger for å starte: kjernen og bootloaderen. På en ekte installasjon finner du dem der, men de nøyaktige filnavnene varierer mellom distribusjoner og oppsett, så det finnes ingen universell liste å pugge. I disse minimale testcontainerne er /boot helt tom.

/srv er ment for data denne maskinen serverer til nettverket, og på en stasjonær maskin er det en tom mappe som mest sannsynlig forblir tom så lenge maskinen lever.

Ett program gjennom treet: bash

For å gjøre kartet konkret, følg ett program gjennom det: skallet du har tastet kommandoer i hele tiden. Tre distribusjoner, tre økter.

Ubuntu:

$ which bash
/usr/bin/bash
$ ls -l /usr/bin/bash
-rwxr-xr-x+ 1 root root 1540520 Feb 13  2026 /usr/bin/bash
$ ls -l /etc/bash.bashrc
-rw-r--r--+ 1 root root 2553 Feb 13  2026 /etc/bash.bashrc

Fedora:

$ which bash
/usr/sbin/bash
$ ls -l /usr/sbin/bash
-rwxr-xr-x. 1 root root 1551104 Jan 16  2026 /usr/sbin/bash
$ ls -l /etc/bashrc
-rw-r--r--. 1 root root 2709 Jan 17  2026 /etc/bashrc

Arch:

$ which bash
/usr/sbin/bash
$ ls -l /usr/sbin/bash
-rwxr-xr-x 1 root root 1195144 Jun 10 04:32 /usr/sbin/bash
$ ls -l /etc/bash.bashrc
-rw-r--r-- 1 root root 733 Jun 10 04:32 /etc/bash.bashrc

Fedoras og Archs svar fra which bash ser ut som om skallet har flyttet til et eller annet adminhjørne. Det har det ikke. På de to er /usr/sbin en symlenke til bin, så /usr/sbin/bash er /usr/bin/bash som nås under et annet navn. Samme fil, annen dør. På Ubuntu er /usr/sbin en ekte mappe, og Ubuntus bash ligger i /usr/bin.

Stoppene i /etc forteller sin egen historie. Hver distribusjon leverer en bashrc for hele systemet, men navnet er annerledes: Ubuntu og Arch kaller den /etc/bash.bashrc, Fedora kaller den /etc/bashrc. Dine egne justeringer legger du i .bashrc i hjemmemappen din, og dermed lukker omvisningen sirkelen, tilbake til de skjulte filene fra begynnelsen. Og den /root-mappen på Arch fra tidligere, den uten .bashrc? Ingenting er ødelagt. En hjemmemappe inneholder det distribusjonen, eller du, har lagt der.

Kartet på én side

Hvor du står nå

Du kan lese en sti som en gateadresse nå. /etc er innstillinger, /var er data som endres, /usr/bin er distribusjonsprogramvare, /usr/local/bin er din. Når guiden Feilsøking borer seg ned i en full disk med du og finner en /var som vokser, blir det ikke noe mysterium: loggene bor der, og logger vokser.

Én distinksjon denne siden holdt seg unna: mapper og filsystemer. Alt over er om mappetreet. Hvilket filsystem (ext4, btrfs, swap) som ligger bak hver del av det, er et eget spørsmål, og kapittelet Disker og lagring eier det.

For den formelle versjonen av kartet, tre kilder verdt å ha:

• Filesystem Hierarchy Standard 3.0, selve spesifikasjonen
• hier(7), manualsiden for hier(7), lesbar på nettet
• Linux man-pages project, prosjektet som vedlikeholder hier(7)

Ingen av dette trenger pugging. Ha tabellen innen rekkevidde, kjør ls på steder du ikke kjenner, så fyller kartet seg selv ut.