10

I'm wondering what the FHS compliant mount points for internal harddrives and networkshares are? Many different tutorials are suggesting to mount them in subdirectories to /mnt or /media

According to the FHS 3.0 (File Hierarchy Standard):

  • /media : Mount point for removable media (This directory contains subdirectories which are used as mount points for removable media such as floppy disks, cdroms and zip disks.)
  • /mnt : Mount point for a temporarily mounted filesystem (This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run)

I assume that those mount points could go to /home/foo/extdrive /home/foo/nfsshare for a single user system, but where would I mount them accessible for all users?

Update: FHS 3.0, Chapter 3.1, second "Rationale" paragraph

  • new directory in / (ie /workspace and /nfsshare) There are several reasons why creating a new subdirectory of the root filesystem is prohibited: It demands space on a root partition which the system administrator may want kept small and simple for either performance or security reasons. It evades whatever discipline the system administrator may have set up for distributing standard file hierarchies across mountable volumes. Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability.
  • Not an answer, but wouldn't an internal harddrive be part of the "normal" filesystem? e.g. you run out of space on disk 1, realise that it's because /var is growing faster than expected, and so install disk 2 and mount it as /var. Interesting qestion re: network shares, it's kind of the "anti-/srv"! – John N Jan 18 '17 at 12:46
  • 2
    "I'm wondering what the FHS compilant mount points for internal harddrives" - It up to you to CHOOSE. How can FHS know where you will mount your HD? It could be your home, your root partition, place to put source code. Depends on what you will do with your internal harddrive. – user34720 Jan 18 '17 at 13:13
13

You make your own mount point directories. If you want to ask why, I can only point to the great answer by Wouter Verhelst.

Internal drives

/mnt is a valid place to make your own if you like, and so is /.

/mnt may have been used for this purpose by some historical installation systems, as well as for removable media (before /media). It's still valid for you to do so, but the system itself is no longer supposed to set up anything in /mnt.

I think it's reasonable to use /mnt if you might make multiple mount points. It makes it easy to see all of them together, and it's known as one of the locations people like to use. Some other people like to use /Volumes - following the OS X system, or /vol. /data is common for a single mount point. /d/ is also used. /disk/ is almost certainly used by some, but may be distracting for storage which is not disk-based.

If you use /mnt, I would also create /mnt/tmp. Then there will still be a convenient directory for temporary mounts, the original use of /mnt which FHS mentions.

Preferred mount points for internal HDDs

It's possible that manually creating mount points under /media is a bad idea on some common systems. Modern Linux OS's will create mount points for removable media automatically, and it's possible the structure they create would conflict, or simply appear inconsistent with your own. You don't say what your system is, but you may be interested in portable guidelines, especially if you're asking about FHS. Note this reasoning is similar to why the FHS says the OS must not populate /mnt.

Mount point for system-wide USB disk

Network filesystems

It is sometimes recommended to mount network filesystems in a dedicated sub-directory e.g. /n/host, /nfs/host or /net/host etc.

For example, if you mount a network filesystem at /host and the network becomes unreachable, ls / may hang when it tries to stat the network filesystem. This could be undesirable and frustrating, at a time when you are already becoming frustrated.

  • The FHS says /mnt is for temporary mounts. What about persistent mounts. While I have gone ahead and made /mnt/data for an extra attached disk, it does feel comforting to have a standards doc recommend what sysadmins should use for additional disks. It's a psychological requirement, mainly. – eternaltyro May 29 at 4:02
  • 1
    @eternaltyro I have the exact same feeling, but there's already a good argument in WouterVerhelst's answer. I tried drafting something to improve on that, but it didn't really. It was mostly just duplication & got in the way of the practical suggestions. Edited to try and make that clear. – sourcejedi May 29 at 10:26
7

When the FHS talks about what you cannot do, then the you it is talking about is a distribution, not a user or local system administrator.

A unix system has only one filesystem tree. You can therefore mount anything in the local system on any place in the filesystem, and you wouldn't be breaking the FHS in any way; after all, the FHS goes to great lengths to stay out of the way of local system administrators. For internal disks that are in the system at all times, it's perfectly valid to have a mount point of /opt or /ntfs or /scratch or whatnot. Alternatively, if you're running out of disk space and you want to move some stuff off your root filesystem and onto another disk, you can move /var or /usr to a separate hard disk and deal with things that way.

The only thing you should not do is to mount an internal disk on a location that the FHS says distributions can write into (such as /usr, /var, or /lib), and then either not move the relevant data to that location, or use some non-POSIX filesystem for the partition in question. Other than that, almost everything is fair game.

  • "the you it is talking about is a distribution, not a user or local system administrator." This is what I needed to hear. Thanks! – eternaltyro May 29 at 11:02
2

To make a directory accessible to specific users, you would create a group. By convention, groups can have home directories. These are sometimes, but not necessarily, created as /home/$GROUP.

It would be possible to create a directory /home/allusers. You could reserve the group name allusers (i.e. create an empty group) if you like. (User and group names are technically separate namespaces, but they are usually kept consistent. E.g. you would not particularly want to create a normal user "allusers" in this case).

This specific naming scheme does not generalize naturally for multiple filesystems, e.g. one internal disk and one network filesystem.

You are not a software distribution, and the rationales given in the FHS does not apply to you. Following this restriction would introduce an additional constraint. If /home becomes unmountable, it would also be less easy to mount /home/allusers for backup, recovery or troubleshooting purposes.

2

Quick answer: It depends... FHS is for distributions as others have said. But you may find it easier to follow at least the spirit of it just for ease of maintenance, especially if this is to be done on several systems that other people might end up supporting. It's also worth bearing in mind how backups are taken as it might save you having to adjust them to take account of the additional space you're adding.

Examples I've used:

  • Big chunk of general shared space on /mnt/play
  • Per-user CIFS mounts via pam-mount on /home/[username]/network/[share]
  • Server applications as per manual eg /sapmnt /opt/whatever /bacula
  • File shares on /srv/[sharename] or /fileshares/[sharename]

Also worth avoiding anything that's used by an automounter such as /media on Mint/Ubuntu or using the listed directory trees for something other than their intended purpose. Eg, it's common to mount a disk to /var/[app] or /usr/[app] to make more space available for that particular app, but don't then use it for something else 'cos you'll only get yourself in a muddle.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.