Noob question: what's the deal with my connected drives not being accessible?

[Aragorn]

@Flygohr

@Aragorn

Note that if you want to include the UUIDs in /etc/fstab, they have to be literally as in the output of the above command, because UNIX is case-sensitive.

Is the UUID part optional?

Well, that depends on how you define “optional”. You need to specify what storage device needs to be mounted where, and the storage device can be mentioned in a few different ways.

1. By its block device name. This is commonly something like /dev/sdb1 for the first partition on the second drive found by the system when it booted. But therein lies the problem, because the order of the physical drives may differ across boots, given that the kernel enumerates them in the order of discovery, and small glitches may cause one drive to get detected sooner than another drive. So this is not a good strategy.

   /dev/sdb1  /where/to/mount/it   filesystem-type-here  mount,options,here    0    1
   

2. By its UUID: UUIDs are unique — unless you’ve manually changed them — and are therefore a secure way of indicating what filesystem you want to mount.

   UUID=some-long-string-here  /where/to/mount/it   filesystem-type-here  mount,options,here    0    1
   

3. By a LABEL. A LABEL is easier to use than a UUID, but it must be set manually by the administrator, which means that your filesystem in question may not have a LABEL attached to it, and if it does, then there’s no guarantee that it’ll be unique.

   LABEL=the-name-you-gave-it  /where/to/mount/it   filesystem-type-here  mount,options,here    0    1
   

There are yet other methods, similar to the above, e.g. by using the PARTUUID or PARTLABEL, but this only works if your drive was partitioned with a GPT partition table; it does not work for MBR-partitioned drives, because they don’t have either a PARTUUID or a PARTLABEL.

The difference between a UUID and a PARTUUID is that the UUID is stored in the filesystem itself, and if it ever gets reformatted, then the UUID will be different. The PARTUUID on the other hand is stored in the GPT partition table, and therefore it will not change if the partition gets reformatted.

Likewise for the difference between LABEL and PARTLABEL, but just as with LABEL, the PARTLABEL has to be manually set, which means that it’s not guaranteed to be unique, and maybe you didn’t even assign a PARTLABEL to the partition.

The bottom line is that using the UUID is the safest bet, especially for newbies.

@Flygohr

@Aragorn

You may also want to add nofail to the mount options, but note that the mount options must be separated by commas only, without spaces between them.

I think I want to include the nofail option to avoid messing up with my boot, right? Worst that can happen this way is that the drives don’t get mounted and I have to troubleshoot from there, yeah?

Yes, that is correct. But you don’t need nofail on your root volume, though. It’s only required for partitions on drives that aren’t guaranteed to be connected to the system when it boots.

@Flygohr

@Aragorn

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

I’ll figure it out, but if I may ask one favor, could you give me an example of a row with permissions listed in the mount options?

Sure. Here’s an example for mounting an ntfs drive…

UUID=some-long-string  /home/your-user-account/my-winfs  ntfs  auto,nofail,uid=1000,gid=1000,utf8,umask=022,defaults   0   0

In addition to all of the above, a special word also needs to be said about btrfs. This does not apply to your additional drives, but it does apply to your root filesystem if you opted for automatic partitioning, because btrfs is now the default filesystem type in new installs as of Manjaro 25.0.

There is ample documentation on btrfs, but I’ve written a short introduction to it at the link below…

• Btrfs as the default filesystem in Manjaro 25.0 — advice for new installations