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

3 Answers 3


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
  • 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

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
  • 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

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.


You must log in to answer this question.

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