En symbolsk lenke er en peker til en annen fil. Når du åpner den, vil filen som den peker til åpnes. Fjerning av linken vil ikke slette filen den peker til. Likeledes har den ikke sitt eget sett med tillatelser, men beholder heller rettighetene til sitt mål. Endelig kan den peke til alle typer filer: Kataloger, spesialfiler (kontakter, navnede kanaler, enhetsfiler, etc.), og til og med andre symbolske lenker.

ln -s mål lenkenavn-kommandoen lager en symbolsk lenke, kalt lenkenavn, som peker til mål.

Hvis målet ikke eksisterer, er koblingen «ødelagt», og forsøke å få tilgang til det vil resultere i en feilmelding om at målfilen ikke eksisterer. Hvis koblingen peker til en annen link, får du en «kjede» av lenker som blir til en «syklus» der ett av målene peker på de foregående. I dette tilfellet vil tilgangen til en av lenkene i syklusen resultere i en bestemt feil («for mange nivåer med symbolske lenker»). Dette betyr at kjernen gir opp etter flere runder med syklusen.

Det er to tidskilder i en datamaskin. Datamaskinenes hovedkort har en maskinvareklokke, kalt «CMOS klokke». Denne klokken er ikke veldig presis, og gir heller trege aksesstider. Operativsystemkjernen har sin egen programvareklokke, som selv holder seg oppdatert (muligens med hjelp av tidstjenere, se Seksjon 8.9.2, «Tidssynkronisering»). Denne systemklokken er generelt mer nøyaktig, spesielt siden den ikke trenger tilgang til maskinvarevariabler. Men siden den bare finnes i et påslått minne, er den nullet ut når maskinen startes opp. I motsetning til en CMOS-klokke, som har et batteri, og derfor «overlever» omstart, eller når maskinen er stanset. Systemklokken er derfor satt fra CMOS-klokken under oppstart, og CMOS-klokken oppdateres når maskinen stanses (for å ta hensyn til mulige endringer eller korreksjoner hvis den er feil justert).

I praksis er det et problem, fordi CMOS-klokken er noe mer enn en teller, og ikke inneholder informasjon om tidssonen. Det er et valg av som skal gjøres om denne tolkningen: Enten kan systemet anse at det kjører i universell tid (UTC, tidligere GMT), eller i lokal tid. Dette valget kan virke enkelt, men ting er faktisk mer kompliserte: Som et resultat av sommertid, er dette ikke konstant. Resultatet er at systemet ikke har mulighet til å finne ut om forskyvningen er riktig, spesielt i perioder med tidsendringer. Siden det alltid er mulig å rekonstruere lokal tid fra universell tid og tidssoneinformasjon, anbefaler vi på det sterkeste å sette CMOS-klokken i universell tid.

Dessverre ignorerer Windows-systemer med standardinnstillinger denne anbefalingen. De holder CMOS-klokken på lokal tid, og bruker tidsendringer ved oppstart av datamaskinen, ved å prøve å gjette under tidsendringer om endringen allerede er tatt i bruk eller ikke. Dette fungerer forholdsvis godt så lenge systemet bare kjører på Windows. Men når en datamaskin har flere systemer (enten det er et «dual-boot»-oppsett, eller kjører andre systemer via virtuell maskin), blir det kaos, uten verktøy til å avgjøre om tiden er riktig. Hvis du absolutt må beholde Windows på en datamaskin, bør du enten sette den opp til å holde CMOS-klokke som UTC (sette registernøkkelen HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal til «1» som et DWORD), eller bruke hwclock --localtime --set fra Debian-systemet for å sette maskinvareklokken, og merke det sporing av lokal tid (og sørge for å sjekke klokken manuelt vår og høst).

NTP (Network Time Protocol / Nettverk tidsprotokoll) gjør det mulig for en maskin å synkronisere seg med andre ganske nøyaktig, tatt i betraktning forsinkelser forårsaket av overføring av informasjon over nettverket, og andre mulige forskyvninger.

Mens det er mange NTP-tjenere på Internett, kan de mer populære bli overbelastet . Det er derfor vi anbefaler å bruke pool.ntp.org-NTP-tjener, som i realiteten er en gruppe maskiner som har blitt enige om å tjene som offentlige NTP-tjenere. Du kan til og med begrense bruken til en under-gruppe som er spesifikk for et land, for eksempel med us.pool.ntp.org for United States, eller ca.pool.ntp.org for Canada, etc.

Men hvis du klarer et stort nettverk, anbefales det at du installerer din egen NTP-tjener, noe som vil gi synkronisering med offentlige servere. I dette tilfellet kan alle de andre maskinene på nettverket bruke din interne NTP-tjener i stedet for å øke belastningen på de offentlige tjenerne. Du vil også øke homogeniteten med dine klokker, ettersom alle maskinene blir synkronisert fra samme kilde, og denne kilden er svært nær når en tenker på nettverkets overføringstid.

I et Unix-lignende system som Debian, blir filer organisert i en enkelt tre-lignende hierarki av kataloger. /-mappen kalles «rotkatalogen»; alle andre kataloger er underkataloger innenfor denne roten. «Montering» er handlingen å inkludere innholdet i en ekstern enhet (ofte en harddisk) inn i systemets generelle fil-tre. Som en konsekvens, hvis du bruker en egen harddisk til å lagre brukernes personlige data, må denne disken være «montert» i /home/-mappen. Rotfilsystemet er alltid montert ved oppstart av kjernen. Andre enheter blir ofte montert senere under oppstart, eller manuelt med mount-kommandoen.

Some removable devices are automatically mounted when connected, especially when using the GNOME, Plasma or other graphical desktop environments. Others have to be mounted manually by the user. Likewise, they must be unmounted (removed from the file tree). Normal users do not usually have permission to execute the mount and umount commands. The administrator can, however, authorize these operations (independently for each mount point) by including the user option in the /etc/fstab file.

Kommandoen mount kan brukes uten argumenter (den lister da alle monterte filsystemer). Følgende parametere er nødvendige for å montere eller avmontere en enhet. For den komplette listen, se gjerne de tilsvarende manualsider, mount(8) og umount(8). For enkle tilfeller er syntaksen enkel også. For eksempel å montere /dev/sdc1-partisjonen, som har et ext3 filsystem, til /mnt/tmp/-mappen, kan du greit kjøre mount -t ext3 /dev/sdc1 /mnt/tmp/.

systemd is able to manage automount points: those are filesystems that are mounted on-demand when a user attempts to access their target mount points. It can also unmount these filesystems when no process is accessing them any longer.

Like most concepts in systemd, automount points are managed with dedicated units (using the .automount suffix). See systemd.automount(5) for their precise syntax.

Other auto-mounting utilities exist, such as automount in the autofs package or amd in the am-utils.

Note also that GNOME, Plasma, and other graphical desktop environments work together with udisks, and can automatically mount removable media when they are connected.