Filesystem Hierarchy Standard - Reference Poster / Cheatsheet [Dark mode in details]

callcc@lemmy.world to Linux@lemmy.ml – 560 points –

Hey, I've recently designed a Poster about the FHS since I often forget where I should place or find things. Do you have any feedback how to make it better?

I updated the poster: https://whimsical.com/fhs-L6iL5t8kBtCFzAQywZyP4X use the link to see online.

Dark mode

Old version

98

Damn that's some great work ! When I started linux I wish I had found such ressources, I was really curious what each of these directories were for.

Would you mind if your material was reused (with credit) for education purposes ?

I'd be more than happy if this was used. Do whatever you want with it as long as you abide by the CC BY-SA-4.0 license. This means you can share freely and modify as long as you keep the authorship information and share with same license.

The FHS was started in 1994 and is free to use. It should be used now by all major Linux systems and most Unix too.

The only credit is to the Linux Foundation.

But $vendor, which supplies $application, doesn't give a flying fuck about this. I've seen binaries in /etc/opt/$application or something like that.

Tell them. Many people don’t know about FHS. Seriously, just the person I was answering to was giving credit to some rando who copy pasted an image from the Linux foundation.

I’ve been educating people on this all my professional life. I try to make a change with the people around me, but I’ve also filed big to some FOSS projects that got it wrong. Some did the change, some were unwilling. But it’s unknown if even those did follow the right convention in their next project.

I spent a few hours making it myself. Of course based on the standard document.

Material visualising or describing FHS can be credited seperatly.

I really like this, but can I have a black background version please?

Added a black background version.

You could invert the colors in GIMP or similar.

That wouldn't look as good tho. I want the black text to be white and the white background to be black not invert everything.

Super useful, thanks. Actually made a lot of things click in my head about how Linux works.

When did /home get deprecated? Is /usr/local the replacement?

Sorry for the n00b question (I'm not a noob, but I have been off Linux for a few years), figured the answer may be useful to other users too

/home is not deprecated, it's optional but common. Here is the section from FHS: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html

then the legend should be fixed its confusing, as is the whole idea of FHS is outdated and a chore for new users to get into (i still don't fully understand it)

  • difference between /media and /mnt
  • wtf is /run? some glorified /temp?
  • /usr/sbin "non vital system binaries" ... aha ok, whatever don't tell me you understand the difference between 6 (SIX !) differen bin/sbin folders
  • could continue forever...

The legend is a bit broken. Will fix it maybe.

As for the rest, yes, the FHS can be confusing. It's from a time where mostly professional admins would deal with it and requirements were pretty different from today's end-user systems. If you want to understand more, I urge you to read the spec. It's highly readable! https://refspecs.linuxfoundation.org/FHS_3.0/fhs.html

/mnt is for more permanent stuff. /run is for shit like a USB drive some user has connected. It's the place that most distro automount your attached storage by default (/run/$USER/$DEVICE/)

I don't understand the ambiguity of where to put your projects.

I've typically always put things under /opt/ TIL /etc/opt was where the config should go.

Depends on the scope of your project. But if they are services for example or you want them to be run by different users on the system, you could either use /opt or /usr/local. There is some discussion about which is better or how to choose: eg. https://www.linuxjournal.com/magazine/pointcounterpoint-opt-vs-usrlocal . The FHS is mostly relevant when packaging your software though.

Less relevant with Docker or FlatPaks though right?

I'm not into those since they just shift the complexity. People should learn how to package things and just do it. Ok, documentation on making dpkgs is pretty tough to understand and confusing.

But yeah, I guess with docker it's complete anarchy ( the bad kind of)

But yeah, I guess with docker it's complete anarchy ( the bad kind of)

Not really, usually stuff will be all self contained (no pun intended), container volumes inside docker's own directory and mounts of folders that will most often all reside under the same repository, then you don't have to worry about breaking stuff by touching the root, even better if you do that with Podman.

Flatpak is similar in the way that it also has its own standards and apps are pretty much obligated to follow them. Now the fact that data lives under .var/app/ completely disregarding the XDG spec, while both things are part of Freedesktop... Well that's just ironic lol

But who knows what's inside?

Not at all true. Go inspect the Dockerfile. If done correctly you should be able to inspect the full container build.

Of course you can, but few people care and do it. There is a saying about docker: "Docker images are like smoothies, you immediately know if you like it but you don't know what's inside". The idea being that there is no good quality control and transparency. People just install random blobs, like in the old days where you would install a cracked game from eMule.

If you care about security, docker is not what you want, they are not reproducible nor transparent nor is it possible to easily update broken shared libraries (eg openssl).

But then again people have different requirements. Some just wanna have things running quickly without the hassle. That's where docker shines. But it leads us to a world where we hide ugly stuff under the carpet instead of fixing things.

Agreed but can't the same be said about pre-compiled binaries?

At least with a Dockerfile I can download the repo and make them image for myself.

Sure you could've downloaded the repo and compiled the binary for yourself but you still had to have all of the libraries setup correctly. It's more about a codified build process that's reproducible vs a "supposedly" working documentation on a git repo of make scripts.

There is a lot of work being done on reproducible builds in the guix project and other distros. The idea being that you can be sure that a binary package is bit for bit the same, whoever builds it and on whatever system. This would be the first time you have complete traceability of what goes into your binaries.

On guix, you can for example install substitutes of packages which you could also build manually. Since the build environment and the dependencies are very tightly controlled, you have mathematical proof that the substitute is equivalent to the package built by the maintainer. You can thus be sure that no evil third party injected malware into the substitute binary, unless ot was done at source code level and the package maintainer has put it there (by accident).

This is a very useful, very well done chart, congratulations.

But what a mess is FHS. Easily the worst thing of linux design for me

The better you understand it the less it seems bad.

I'm surprised to hear /home is non standard.

I guess the reason it's not in FHS is that FHS is concerned about system wide things whereas /home is the opposite. It's the user's realm.

There is XDG for /home/$user though.

laughs in guix

does guix go the same was as nixos in that regard? where can I find info regarding FHS in guix?

Afaik guix is very similar to nixos in that respect. The store where applications are installed is called /gnu there.

yeah it uses /gnu instead of /nix

Great but what I'm missing is the information that "usr" does not stand for "user", like many people think or even say. If it would the name could actually be "user" and not "usr".

The chart actually does not say what exactly it stands for. It's "user resources" AFAIK.

It's worth clearing this up in my opinion.

Thanks for the input. Things are complicated: https://askubuntu.com/a/135679 . Apparently it originally meant "user" but then slowly was used for system stuff. So people invented backcronyms.

That's just retconning/backronyming it.

/usr does historically stand for user. It's where the user home directories were on old Unix versions.

how is /usr/local local and not system-wide? i though it was for programs you compiled yourself?

"Local" in this context means local to this whole machine. From the perspective of a single user, it's system-wide. But then from the perspective of a sysadmin managing dozens of such systems, it's local.

Many FHS things don't make much sense for single-user (human user) systems on modern hardware. /usr/local does though. It's for you (as admin) to install software that doesn't come with the os.

Laughs in Nix

well nix still uses the same structure, the only difference is that files are symlinked to files in subfolders of the /nix/store folder.

For example you may find that /etc/hosts is just a symlink to /nix/store/69420aaabbbcccdddfffggghhhiii420-hosts

Not everything is in its FHS location, unless you use steam-run. Binaries arwn't in /bin, for example

Nicely done! Do you perchance have any hi res version?

Thanks! Unfortunately I've used closed source whimsical.com for this and don't have a paid subscription. They only offer low-res for those accounts since recently :(

Maybe some AI upscaling could do the trick ?

So why does my system mount my drives to /run/user/1000…?

1000 might by your user's user-id

1000 is the default ID given to the first-created user on Debian-based systems.

May or may not be the case with other distros. Haven't checked.

I've never seen /etc/opt used. Usually if an app is in /opt, the entire app is there, including its config which is frequently at /opt/appname/etc/.

/opt is kinda legacy at this point. That used to be the location where you'd install software manually in the past but I haven't seen it used for some time, it was more common in the 00's.

I still put all my standalone apps in there (meaning apps that are often statically compiled and expect the executable, logs, and config to be in the same directory), as well as apps that have their own docker-compose.yml file. Should I be putting them somewhere else? I know /srv exists but I've never used it and I don't think Debian creates it by default.

And /net is usually autofs mounted.

That's NFS shares? I might add that later although it's not very common or standard I guess. Thx

Yeah, nfs exports that can be mounted by HOSTNAME or ip address automatically with autofs. Sorry if that’s not standard, like my other comment about /mnt. I’ve never actually looked at the spec. I was just giving feedback based on what I’ve seen in the industry. So might not be spec compliant but a lot of it is common practice I’ve seen (for better or worse.)

What do you mean by locally vs site wide? For /usr/local that’s usually stuff installed from outside of the distributions normal packaging mechanism. E.g. if you build something from source using “make”, the “make install” would install it there by default (though that is also configurable.)

Also not sure we want to say /mnt is necessarily temporary. Any mount pionts there could easily be added to fstab.

The FHS says the thing about /mnt. It's not normally meant to have subdirectories or be mounted to by default.

The origin is that /usr may be network mounted or otherwise shared across multiple systems, whereas /usr/local is local to a particular PC. That definition is not as relevant with today's single-user machines, and now it mostly means what you said (/usr is managed by system package manager whereas /usr/local is manually managed).

What would a use case be for

>/usr/bin

versus

/usr/local/bin

Binaries in the former are installed by the OS/package manager, binaries in the latter are installed manually by the user, for example by compiling from source and running make install

Great. Now I gotta refactor some scripts.