Directory structure question

I didn’t really mean to put this in the support forum but given the current forums I don’t really see where else to put it. I looked at the wikipedia pages for the unix file system hierarchy and linux one. Both say that the media folder is where usb stuff gets mounted but I know that my kde system it mounts usb stuff to /run/media instead /media. Why is that and why doesn’t /media exist on my system? The unix file system artcile has no mention of a /run directory but the linux one says this about it.
Run-time variable data: Information about the running system since last boot, e.g., currently logged-in users and running daemons. Files under this directory must be either removed or truncated at the beginning of the boot process, but this is not necessary on systems that provide this directory as a temporary filesystem (tmpfs).

Also I noticed that my root directory / not /root now has two txt files desktopfs-pkgs.txt and rootfs-pkgs.txt. Why aren’t these kept in a subdirectory? Can I remove them without causing a critical issue?

Heh I guess this is a support thread or more like a mix of support and directory structure discussion.

The FHS as this is called is only a guide with the intention of giving distribution builders and developers a predictable location for various configurations and locations for service content.

The most interesting locations are

  • /run - which is a volatile structure getting created at runtime.
  • /mnt - a location for temporary mounts
  • /srv - a location used the contents for services like nfs, http, ftp etc.

Some uses /mnt as a base for permanent mountpoints - but there is a number of reasons why this should be avoided.

  1. Permissions
    Change the permissions on a system folder in the root tree is always a bad idea.
  2. Assumptions
    Some applications or scripts are designed to mount their working image in /mnt and as it is entirely possible to mount at a used location - which hides the previous content - it may create illogical errors when other scripts or applications or your data storage suddenly disappears.

This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems. - Filesystem Hierarchy Standard


The FHS document has a limited scope:
Local placement of local files is a local issue, so FHS does not attempt to usurp system administrators.
FHS addresses issues where file placements need to be coordinated between multiple parties such as local sites, distributions, applications, documentation, etc. - http://www.pathname.com/fhs/pub/fhs-2.3.html#INTRODUCTION


This topic is a possible beehive - and has often been misused to argue for someone’s own belief - creating heated arguments - so l suggest we leave at the user’s own decision on how to organize their own files.

Topic is closed to avoid beating a dead horse - nothing personal.

It is more or less distribution-specific, and to be even more precise, whether a distribution boots with and runs a traditional sysvinit or whether it’s a distribution based upon systemd.

Manjaro runs systemd as its init system and service manager, and systemd makes heavy use of tmpfs for lots of things that under sysvinit were done by way of on-disk filesystems and directories. For instance, in most systemd-based distributions, the contents of /tmp live on tmpfs, not on a permanent storage medium such as an SSD or HDD.

One of the main differences in mounting removable filesystems is also that systemd regards those as private mounts. In other words, if you plug in a removable storage device, then systemd will (offer to) automatically mount the filesystem, but this is a private mount, meaning that it’s only available to the user sitting at the console, not to remotely logged-in users, and there is more emphasis on the fact that it is a temporary mount ─ i.e. the device does not have a record in /etc/fstab. As such, the /media directory has been replaced by /run/media. :wink:

One of the design goals of the systemd developers is to convert GNU/Linux into a so-called stateless operating system. Whether this is desirable or not is open for debate, but at present time ─ and hopefully this will be how the development continues ─ systemd does still allow for lots of versatility, so that not everything in the system needs to conform to the concepts of a stateless system, while at the same time not corrupting the system’s integrity with those things for which a stateless configuration would indeed be more desirable than the traditional one.

systemd has a lot of opponents ─ and I used to be one of them ─ but it truly is a very advanced system daemon, and it’s very flexible. I personally consider it progress, and I’ve been exclusively using GNU/Linux for over 20 years now, as well as that I’ve also worked with a couple of traditional and proprietary UNIX versions. :wink:

it’s more “only available to the user mounting it” as on unix/linux more than 1 user can be connected “localy” at the same time not only remote connected…
but it could also be achieved by mounting it in /media. as it’s just a permission setting, :wink:

Strictly speaking, you are correct, but most of the common hardware that we’re dealing with here at the forum does not come with multiseat provisions. :wink:

Also, I think that the default udisks configuration is such that it is effectively “the user sitting at the console” who gets access to removable storage devices, since in most x86-64 and aarch64 machines, those devices are plugged into the chassis’ I/O ports, and the console itself also has its ports directly on the motherboard. :slight_smile:

but if you have 2 keyboard, 2 mouse, etc… you can have to 2 xorg session with 2 user working at the same time on the same machine… it’s what I meant… :wink:

Yes, but that’s a multiseat setup, and it’ll only work when X.Org is running. The Linux console itself is not multiplexed ─ albeit that efforts have been made (and abandoned again) at creating a multiplexed console. :wink:

it can if you have serial terminal connected to serial ports… :innocent: you can do almost all what you want with linux… at school we had a unix sever with about 30 serial terminal connected to it… :wink:

your answer is correct… as it’s multi-user system… to avoid “possible” mounting point confflict, permission issue… all mounted usb device is mounted in a user owned place… and they decided to do it in /run/media/username/…
it could have been /media/username it would not change… just that /run is created at boot then don’t let any artifact when reboot…

https://lists.fedoraproject.org/pipermail/devel/2014-August/201457.html

and for info command systemd-path return some path

1 Like

@Aragorn
Thanks for reopening the thread I’ll adhere to what linux-aarhus said and make sure it doesn’t get out of hand. I should’ve figured I was beating a dead horse but since I don’t know the story behind it I’m glad to find out. Please keep it open at least for now.

Yeah I thought about that but tmpfs dirs are usually wiped after every reboot (as the definition of /run describes so that’s why I wanted to ask. I had no idea systemd was responsible for this. I hate to say it but despite it’s ease of use with enable/disable/start/stop/restart for services I’m starting to see why not everyone is a fan of systemd because for example in this case it gives them impression that my usb stick will be wiped if I reboot my machine. (I know this doesn’t happen but hopefully you get my point)

No, that’s just a duplicate of or substitute to the main console. The Linux console code lives in the kernel, and does not allow for multiplexing. You can have virtual consoles, yes, but considering that Linux ─ the kernel ─ was developed on x86, multiplexing was never built into the console subsystem. This is one of the things where it differs from proprietary UNIX.

Like I said, alternatives have been under development ─ even by the systemd developers themselves ─ but they have all been abandoned. :man_shrugging:

So I´m sitting here and trying to answer my thoughts on this question, too.
But the (easy) answer is still not there, right?

I want to mount:
External HDD, NFS/SMB shares, local (Windows) partitions

WHERE is best practice to mount them in Manjaro?

Just create a /media directory and forget about it? At least this directory is found in many many manuals online. Or mount them in /run/media as Dolphin does it when I click on it? Or maybe in different directories depending on what to mount?

Why aren´t these BASIC questions not answered in the wiki?
I am pretty sure, I am not the only new to Linux user who is annoyed by all this little things not just beeing readable at the official pages…

Oh and I forgot about reading that (at least on Gnome[Ubuntu?]) mounting in some places has an impact on the appearance in the GUI, too. What about KDE?

Hello, do these already give you some answers?


1 Like

Just going to drop this video resource for people to watch. Chris Titus Tech also has a similar video, but this one’s a good enough starting point for anyone wanting to begin their understanding of the FHS.

1 Like

For the external HDD, it depends what filesystem is on there, and what you use that device for.

You should first and foremost reconcile yourself with the fact that GNU/Linux is a UNIX-style system, and that you are most likely using your computer along the lines of the Microsoft Windows paradigm. Well, there are things in any modern GNU/Linux distribution that will meet you in that regard, but it’ll never be the same as in Microsoft Windows, because this is an entirely different operating system architecture, and it should be used differently too.

Unlike in Microsoft Windows, UNIX operating systems do not approach storage by way of volumes or “drives”, but rather as a uniform directory hierarchy, which will always look the same to the user, regardless of whether the contents of any particular directory are on the same partition, a different partition, a partition on another physical storage device, or even another computer on the network.

With all of the above in mind, programs are not stored where you would store them under Microsoft Windows, but instead, it has always been one of the characteristics of UNIX that programs are merely extensions to the base operating system, and as such, their files will be installed where the operating system files are installed. This means /usr/bin for executables, /usr/lib for libraries, and so on.

As such, an external HDD would normally be regarded as a non-essential component to the hardware ─ e.g. for storing backups. But if you’re coming from the Windows world, then maybe your HDD contains executables, or games, or something else altogether. And you will be approaching your system as a single-user machine, whereas UNIX was designed and intended to be used as a multiuser operating system from the ground up.

Ergo, if your external HDD contains personal stuff, then the best place to mount it would be under your home directory somewhere, and especially so if it has an NTFS filesystem on it, because NTFS does not store POSIX file ownership information or POSIX permissions, and so the ownership and the permissions must be faked and set for the entire filesystem at mount time. Therefore, putting it under your $HOME and mounting it to a directory owned by yourself ─ as opposed to a system directory owned by the root account ─ would be the best solution.

As for network storage, I would recommend a directory /network, or /mnt/network ─ you could also make a /srv/network, but that would more typically be for if your computer is the server in the network, rather than a client.

Either way, always remember that Microsoft Windows was originally designed as a single-user platform ─ and most specifically, as a graphical user interface on top of MS-DOS, a single-user and single-tasking operating system ─ whereas UNIX was designed with concurrent multiuser access and a centralized security administration in mind.

There is ample documentation on the web regarding how UNIX systems are organized, and I am planning to write a more elaborate tutorial at some later point in time, but for now, :duck: :duck: :walking_man: is your friend. :slight_smile:

1 Like

I really appreciate your replys. But I am not looking for an explanation of how the whole unix ecosystem is made and why and so on. I - as a new user - am just looking for some easy and simple guideline. And if I am more interested after that, I surely can inform myself more if I want to. But it´s really not interesting as a simple deskop user of how everything is organized and the ethic behind - I just want to get my stuff done. That simple. Why not giving new users just some “best practices” examples. Like something Aragorn has written but in short and simple way?

I am really willing to get rid of Michaelsoft Binbows but even me as a tech guy with many years of computer experience is finding it way to complicated for that basic tasks as connecting my data storages in the “right” way.

Maybe I can better clarify with some other example:

I want to cook noodles.
There are many ways I can do it. Boiling water with gas, electric oven, microwave, making my own fire with wood, using solar energy and what else.

If I ask you, how to cook noodles.
Don´t tell me about all these options and their economical and ecological reasons etc. Just tell me: Put water in pot and heat it up on your stove. Put noodles in and boil em for x minutes. Best practice for usual use case in todays time.

Hope I am not p…g someone off as English is not my native language. Greetings =)

EDIT:
And I use Qwant as my search engine of choice ^^

I mounted my drives as folders under /mnt. For example /mnt/storage for my storage drive /mnt/backup for my backups drive etc.

There is a program called Disks which can edit the fstab file for you. You go to mount options tell it to mount at startup and in the options you can either allow it to create a mount point using the unique drive id or you can specify a folder that you have created to be the mount point.

You mean, gnome-disks from the gnome-disk-utility tarball? That’s default in most GTK desktop variants of Manjaro if I am not mistaken. I do use that, and would advocate 100% for it but flag handling is garbage, which mandates installing the gparted tarball for that utility. Never bothered to check if KDE’s partitionmanager has flag editing.