Mounting of USB drive within rc.local works only until I log-in

Question

This worked prior to current upgrade.

Here's my rc.local (fragment):

date > /tmp/rc.log
sleep 20
mount /dev/sda2 /mnt/sg3t/
df >> /tmp/rc.log
sleep 10
df >> /tmp/rc.log

after login, rc.log shows the drive properly mounted both df outputs, yet df shows it's no longer mounted once I login or SSH in.

Within the file manager giu tool, I have automount of insertable drives disabled.

After login, I can sudo mount as above and it works; but the drive is needed permanently, not per login.

I also tried fstab; but I must have it wrong as the system booted into protected mode.

/dev/sda2 /mnt/sg3t vfat defaults 0 0

I also tried fuseblk as fs-type (it's what df -T returns), same boot fail.

suggestions/corrections?

Answer 1

I don't understand the fascination with using rc.local to mount a drive, but it should work as long as you remember there are two different users involved: the root user for rc.local, and you (whoever you are, you didn't say). Here's a link that discusses this, but I haven't tried it.

I typically operate as user pi, and I make an entry in fstab for my 16 GB SanDisk USB drive. Here's what I do:

man fstab, and read it... In perusing man fstab, some of the documentation available online and advice on fstab that's published, we soon recognize there are some decisions to be made - options to be selected. There are six (6) fields in a fstab entry. Let's do them in order:

1. fs_spec This is the most critical field. The oft-used specifications here are device node (e.g. /dev/sda1), LABEL and UUID. There are several other specs, but these 3 are sufficient for now. Some advocate using the UUID spec and point out that it is more unique and therefore safer than the device node. But we're going to use the LABEL specification, and here's why: We can set it; we have control over the value of LABEL, whereas we have no control over the so-called UUID. In fact, for all types of FAT partitions, they do not have a true UUID. The identifier shown as UUID by lsblk --fs isn't actually a UUID at all! This is a rather murky back alley.
2. fs_file This is mount point we used earlier; in our case: /home/pi/mntThumbDrv
3. fs_vfstype This is the file system type of the drive (or partition) to be mounted: vfat
4. fs_mntops A comma-separated list of options. We'll use: rw,user,nofail (no spaces) which will tell the OS that the drive is read & write, users may mount the drive, and no error will be flagged if the device is not present at boot time (and stop the boot process!).
5. fs_freq A flag that determines if the file system will be dumped; 0 for our case
6. fs_passno A flag that determines if the file system will be checked by fsck, and the order it's to be checked; 0 for our case

After working our way through all the fields, our fstab entry looks like this:

LABEL=SANDISK16GB /home/pi/mntThumbDrv vfat rw,user,nofail 0 0 

Try this, and let us know if you run into issues. You may also wish to take a look at my GitHub page for more technical drivel on this subject. Also, keep in mind that much of this is now done under control of systemd instead of mount, but AFAIK the role of fstab and the functionality of mounting a disk is similar to mount.

Answer 2

AFAIK fuseblk is how NTFS drives look in mount output. Hence the suggestion to use ntfs option in fstab:

/dev/sda2 /mnt/sg3t ntfs defaults 0 0

If you insist on your rc.local solution, you can try to prevent the system from fiddling with your mounts by uninstalling the udisks2 package. Obviously, don't expect the system to auto-mount anything after you do.

Alternatively, you can keep udisks2 and use it to mount your disk from rc.local:

udisksctl mount -b /dev/sda2