Difficulty: ★★☆☆☆
1. INTRODUCTION
Microsoft Windows started its life as a graphical user interface on top of MS-DOS, a 16-bit single-user, single-tasking operating system that in turn originated as 86DOS, an unauthorized 16-bit rewrite (by Tim Paterson of Seattle Computer) of Digital Research’s originally 8-bit CP/M operating system. Both CP/M and MS-DOS were at the time developed for computers that did not support any other storage media than floppy disks.
Considering this legacy, Microsoft Windows still uses the concept of “drives” and “drive letters”, but this concept does not exist in GNU/Linux, because GNU/Linux is a UNIX-family operating system, and UNIX itself was designed as a multitasking, multi-user platform that was modeled after the Multics mainframe operating system, which used a single, unified directory hierarchy where everything can always be found at the same location in the tree of directories ─ or “folders” in Windows-speak ─ regardless of what physical medium it is stored on.
Now, given that the vast majority of our members are (or have until recently been) Windows users, many of them have data stored across various different physical storage media, whether they be external and removable media such as (for instance) USB sticks, or whether they be additional partitions on their internal or external SSDs or HDDs. As such, a question that we get all too often here at the forum is “How can I access the data on my other partition/drive?”
It is these members that this particular tutorial is intended for, as an intermediary step in transitioning away from the Microsoft Windows paradigm and onto the UNIX paradigm, because these two platforms are indeed radically different, and one can never expect to reach a high level of productivity and comfort in GNU/Linux by clinging onto the paradigm of Microsoft Logic™.
2. AUTODETECTION
Manjaro, being based upon Arch, uses systemd as a system daemon, started as the very first userspace process after the kernel has finished booting and loading its driver modules.
systemd is not a single program, but a whole framework of different modules that all work together in a tightly integrated manner. Among other things, it takes care of loading additional driver modules, setting up the login consoles, starting and managing other system daemons ─ i.e. background services ─ and detecting additional hardware as it is plugged into the system.
Therefore, in most cases, systemd will automatically detect any additional partitions and storage media you have, and it will then make those available by way of a mountpoint ─ i.e. a directory ('folder") ─ under the /run directory. However, there are two caveats here…:
-
systemdwill automatically assign a default set of permissions to the new mountpoint, depending on which type of filesystem is mounted on it, which sometimes leads to permissions issues. -
Considering that
/runis itself atmpfs─ i.e. a temporary filesystem that only exists in virtual memory and will thus cease to exist when the machine is shut down ─ manually changing the permissions on the mountpoint for the new filesystem will not persist across reboots.
3. SETTING UP A STATIC MOUNTPOINT
Considering the potential for permissions issues, the better solution for mounting additional filesystems into the directory tree is therefore to set them up with a static mountpoint and permanent permissions. You do this by adding an entry for the additional filesystem in /etc/fstab.
/etc/fstab is a simple text file, in which each line is regarded as a record that describes a filesystem, and each record is divided into six fields, separated by whitespace ─ i.e. spaces or tabs.
A typical filesystem entry might for instance look like this… 
# Anything starting with a "#" is a comment.
#
# -1 - -2- -3- -4- -5- -6-
# ↓ ↓ ↓ ↓ ↓ ↓
# STORAGE | MOUNTPOINT | FILESYSTEM | MOUNT | DUMP | PASS
# DEVICE | | TYPE | OPTIONS |
UUID=some-string /home ext4 defaults 0 0
In the example above, you can clearly see the six fields, and their function should be clear enough by now. However, I will offer some further clarification on account of the 4th, 5th and 6th fields.
-
Mount Options: You can specify multiple mount options there, but they must be separated by commas and may not contain any spaces, because spaces are used as the field separator that distinguishes between the different fields of the record. A valid entry would for instance be
defaults,auto,ssd,noatime,nodev. -
Dump: This field is only there anymore for compatibility reasons, although it is still functional. It denotes whether or not a particular filesystem is eligible for backing up when the
dumputility is used.dumpis an old UNIX backup utility that is still supported onext3/ext4filesystems ─ other filesystems may provide for a more customized alternative in their respective toolkit ─ but these days, much better backup solutions exist, such as TimeShift or BackInTime. -
Pass: This field specifies whether the filesystem must be checked at system boot. A value of “0” denotes that the filesystem must not be checked, while the values of “1” and “2” determine the priority of checking.
4. THINGS TO CONSIDER
Now, how exactly you should set up a mountpoint and an /etc/fstab record for your additional filesystem depends on a couple of different things…:
-
Is the filesystem a partition on an internal storage medium, or does it reside on a removable drive?
-
Does the filesystem support POSIX file ownership and permissions ─ or otherwise put: is it a Linux-native filesystem ─ or is it a DOS or Windows filesystem?
-
Is the content of the filesystem to be shared among all user accounts on the system, or is it data belonging to one user only?
If the filesystem in question resides on a removable drive, then chances are that this device isn’t always connected, and then if the device is indeed not connected when the machine boots, the boot will stall. This is why you should always include the mount options noauto,nofail to the /etc/fstab entry for such a filesystem.
If the filesystem is not POSIX-compatible ─ e.g. it is an NTFS partition ─ then it cannot store any information about file ownership and permissions. However, being a POSIX operating system, GNU/Linux requires every file to have an owner, a group and a permissions mask.
Therefore, when a non-POSIX filesystem is mounted into the virtual filesystem layer of the kernel, the kernel will emulate a mask of fake ownership and permisions to the whole mounted filesystem. Considering that this ownership and these permissions are emulated and set for the whole device at mount time, they cannot be altered for individual files and directories (“folders”) on the filesystem, nor can they be altered for the whole filesystem without remounting the filesystem.
If you want to know what mount options exist for setting the compatibility options for non-POSIX filesystems, then please Read The Fine Manual™ (“RTFM” 
) for the mount command.
man mount
Lastly, there is the choice of where to create the mountpoint. In a UNIX system, the root directory is read-only to unprivileged users ─ only the root account can write to /.
Therefore, if the device contains files that are only pertinent to one particular user, then it is best to ─ as the user ─ create a mountpoint inside the user’s home directory. That way, the mountpoint will be owned by and writable to the user by default ─ you would simply create a directory (“folder”) inside your ${HOME} and use that as the mountpoint.
Do however keep in mind that the permissions on the content of the filesystem will be dictated by what type of filesystem it is…
-
If it is a non-POSIX filesystem, then the permissions on the individual files are emulated, and they will depend upon the mount options for the filesystem as specified in
/etc/fstab, as explained higher up already. -
If it is a POSIX filesystem and it already contains files, then the permissions and ownership that were already in place will still apply. So if the filesystem contains root-owned files, then this will not change, and those files will still be root-owned.
Now, if the POSIX filesystem contains files owned by a user account that doesn’t exist on your system, then the owner and group will be represented as a number ─ the UID (“user ID”) of the user who owned those files on the system that it came from.
This UID may or may not correspond to your own UID. If it does, then great ─ then your own user name will be listed as the owner. If however it doesn’t correspond to your own UID, then you must change either the ownership or the permissions on those files, and on the directories that contain them. See…
man chown
… and…
man chmod
Now, if the filesystem contains files that are to be shared among multiple user accounts, then there are two possible other locations where you can set up a mountpoint, i.e.:
- a directory under
/srvfor filesystems on non-removable media; or - a directory under
/mediafor filesystems on removable media.
The directory /media may not necessarily exist on your system, but it is trivial to create it. You will however need elevated permissions to do so, because unlike in Microsoft Windows, an unprivileged user account has no write access to anything outside of their home directory, /tmp and /var/tmp.
If you decide to share the contents of the additional filesystem with the other user accounts on your system, then there are various options to choose from on account of what permissions and ownership to set for the files on said filesystem ─ provided of course that it is a POSIX-compatible filesystem. I am therefore going to include links below to two other tutorials I’ve written. The first one deals with POSIX file ownership and permissions ─ which allow for far more flexibility than you’re probably expecting ─ and the second one deals with the repurposing of an empty extra partition in the event that your root filesystem is getting full.
I hope this tutorial was useful to you, but if you have any questions, then please post them below on this thread; do not send me any PMs about it, because that would not benefit anyone here on the forum. 