41

mount -a works fine as a one-time action. But auto-mount of removable media reverts to settings that were in fstab at the last reboot.

How to make the OS reload /etc/fstab so auto-mounts use the new settings when media is connected?

The specific example seen with Raspbian (Debian) Stretch:

  • FAT-formatted SD card; configured fstab to auto-mount; rebooted; volume auto-mounts, but read-only.

  • Changed umask options in /etc/fstab; mount -a while media is connected, and volume is now read-write.

  • Unmount and re-insert the media; auto-mount works, but using the options in /etc/fstab from the last reboot, so volume is read-only.

  • Reboot; OS loads updated /etc/fstab; auto-mount works when media is connected, and volume is read-write. How to get this effect without a reboot?

FWIW, the (updated) /etc/fstab syntax was:

/dev/sdb1   /Volumes/boot   vfat    rw,user,exec,nofail,umask=0000  0   0
0

3 Answers 3

33

I suspect this is caused by systemd’s conversion of /etc/fstab; traditional mount doesn’t remember the contents of /etc/fstab.

To refresh systemd’s view of the world, including changes to /etc/fstab, run

systemctl daemon-reload
6
  • Sigh. An auto-generated comment in the top of /etc/fstab reminding/advising people it has now been deprecated - and how to update systemd - would go a long way. Oct 25, 2018 at 20:14
  • 2
    Thanks! You can imagine Google returned nothing but 'mount -a' hits for this query. Are there any unwanted side-effects when doing this on-the-fly re-gen of the tables? Doesn't seem to be.
    – RichardH
    Oct 25, 2018 at 21:45
  • For more, see unix.stackexchange.com/a/236968/5132 and unix.stackexchange.com/questions/90723 . Note that the Debian service that used to run mount -a is nowadays masked.
    – JdeBP
    Oct 26, 2018 at 0:03
  • Your answer (systemctl daemon-reload) now appears as a "hint" from systemd, but It would appear that "something else" is causing it because I still get this occasionally from current systems in 2024. Is there an update to your answer?
    – Seamus
    Apr 15 at 1:36
  • @Seamus this has always worked for me; my crystal ball is perhaps defective, so I can’t guess what could be needed in an update. Have you tried restarting the file system targets? Apr 15 at 8:29
24

To elaborate the answer from @Stephen Kitt: for example I have this entry in /etc/fstab:

vnetsvr-home:/etc/skel   /etc/skel    nfs4   sec=krb5p,noauto,x-systemd.automount,x-systemd.idle-timeout=10min   0   0

and only doing sudo systemctl daemon-reload doesn't reloaded the fstab. I have to do:

sudo systemctl daemon-reload
sudo systemctl restart remote-fs.target

To reload an entry to mount a local filesystem, you should use:

sudo systemctl daemon-reload
sudo systemctl restart local-fs.target
5
  • This answer worked for me in regards to Ubuntu 16.04 while the accepted answer did not. Dec 30, 2020 at 10:17
  • Even this answer does not help me when removing entries from /etc/fstab. So, I opt for the reboot. Dec 30, 2020 at 10:24
  • If you're using "noauto" option, this answer resolves the issue.
    – Ahmet
    May 19, 2021 at 5:21
  • This answer worked for me in RedHat 8, however, the accepted answer did not.
    – caot
    Mar 23, 2022 at 16:47
  • This answer worked for me in Ubuntu 18.04 Nov 1, 2022 at 3:42
0

I know that these solutions might not work in every linux distro and version. However this method would generally works for all Linux versions.
1- Do your configuration and change the fstab file
2- Use this command to remount the device_file you have changed its configuration in the fstab file:
# mount -o remount [device_file]
This way you will mount the partition with its new configuration read from "fstab" file.
If you removed a partition from "fstab" file, simply umount [device_file]. Be sure, the partition stays unmounted after the reboot.

Any time you can check the result by running mount command.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .