I do not manage to get a remote directory automatically mounted during bootstrap. I am using the NFS protocol under Ubuntu 14.04 LTS. The server is and the client is

The setting in /etc/exports at the server side is


Although the \home\user directory at the client side is, note that all directories mentioned in this post are not encrypted. The server computer is always on, and the two machines can ping each other. Also note that, in both machines, the \home directory is mounted on an own partition.

The command line works well and I can see the remote content at the mount point after sudo mount /home/import/server1.

Like in How to edit /etc/fstab properly for network drive? I want to mount a network drive by editing /etc/fstab. However, when I add any one of those lines to /etc/fstab

[1] /home/import/server1 nfs rsize=8192,wsize=8192,timeo=14 0 0

[2] /home/import/server1 nfs auto 0 0

[3] /home/import/server1 nfs auto, rsize=8192,wsize=8192,timeo=14 0 0

[4] /home/import/server1 nfs defaults 0 0

I need to launch a sudo mount -a manually to get the view on the server side. This defies my expectations and those from this U&L post as well.

How can I get the auto-mounting capability running on its own feet?

Inspirations/copy-catting disclosed:

[1] https://help.ubuntu.com/14.04/serverguide/network-file-system.html

[2] https://help.ubuntu.com/community/SettingUpNFSHowTo#Mounting_NFS_shares_in_encrypted_home_won.27t_work_on_boot

[3] = [1] + [2]

[4] mimicking the mount options of the local device partitions in etc/fstab

  • Have you dug into boot / error logs? There might be useful messages there. Also what kind of network connectivity do you have? I suspect it does not work because your network is not online when the mount is attempted but that's just an educated guess.
    – Olivier
    Commented Dec 20, 2016 at 14:33
  • @Olivier Could you please give direction to which files I should look into? Also note that, in both machines, the \home directory is mounted on an own partition, so perhaps mounting \home\exports\* afterwards from \etc\fstable suffers from this nesting... (new info added to the question) Commented Dec 20, 2016 at 14:45
  • should be something like /var/log/boot.log on ubuntu 14 but I think Sagar has the answer to your problem already. _netdev will let the boot system know to wait until the network is working to do the mount.
    – Olivier
    Commented Dec 20, 2016 at 14:58
  • @Olivier /var/log/boot.org shows only one suspicious fail at line 1 * Starting Read required files in advance[234G[[31mfail[39;49m], all the other operations featuring mounting and network are [ OK ]. One other fail deals with printers and a NSM status monitor. Sagar's solution to this moment is not effective either. Commented Dec 20, 2016 at 17:58
  • Try adding bg to your mount options in /etc/fstab.
    – Olivier
    Commented Dec 20, 2016 at 21:04

4 Answers 4


If your mount -a option works then you should add _netdev in fstab. /home/import/server1 nfs defaults,_netdev 0 0

Also make sure for "chkconfig netfs on"

  • 2
    Nope, unfortunately. After your line I still need to launch sudo mount -a to get the mounting done. Also, chkconfig is no package supported by Ubuntu, if I am not wrong (I myself had launched a sudo service nfs-kernel-server start earlier -- but that's on the server's side anyhow, I believe, while I am struggling at the client's side) Commented Dec 20, 2016 at 17:40
  • Please share your boot logs. _netdev is for network device and mounts the device once network service is up.
    – Sagar
    Commented Dec 22, 2016 at 2:26
  • Also share output of "tail -1 /etc/mtab " after firing sudo mount -a.
    – Sagar
    Commented Dec 22, 2016 at 2:33
  1. Create a file at: /etc/network/if-up.d/fstab

  2. Add this to it:

    mount -a
  3. Make the file executable:

    sudo chmod +x /etc/network/if-up.d/fstab

You are directing the system at boot time to issue a mount -a after the network stack is up and operation which if it's like a cifs mount in fstab is the reason your shares are not mounting at boot.

From this answer: nfs shares in /etc/fstab not loaded on boot in 18.04 at Ubuntu forums.


TL;DR: try sudo apt install openvswitch-switch-dpdk then reboot to see if it works.

I've encountered the same problem on Ubuntu 22.04 and managed to solve it.

Following the link (nfs shares in /etc/fstab not loaded on boot in 18.04) shared in the answer of @LiberiFatali, I found some guy mentioned:

For me the solution was to edit the netplan configuration (/etc/netplan/50-cloud-init.yaml)file and set interface as optional: false

This is supposed to be the default behavior of netplan, but I decided to give it a try. After I edited the config and execute netplan apply, I got the warning: Cannot call Open vSwitch: ovsdb-server.service is not running. Although this post says it's a bug and the the warning can be ignored, I'm not fond of warnings and tried to get rid of it by sudo apt install openvswitch-switch-dpdk. And after rebooting the nfs was magically mounted! I further reverted changes in the netplan config file to confirm that simply installing the package can make the fstab auto mounting work.

I'm not an expert of Linux systems and don't know how the magic happens, but it might worth a try for ones of same conditions. Good luck.


As the multitude of answers shows, there can be several reasons. Digging through the log files is probably mandatory.

In my case (this was on RHEL 7), this was caused by a dependency loop. Systemd had converted the fstab entry into a mount unit that depended on the nfs-server service, and vice versa. I don't fully understand why, but in my case that was not necessary to solve the problem.

Here is what I found in /var/log/messages

systemd: Found dependency on home.mount/start
systemd: Found dependency on nfs-server.service/start
systemd: Breaking ordering cycle by deleting job home.mount/start
systemd: Job home.mount/start deleted to break ordering cycle starting with nfs-server.service/start

Which of the two gets deleted is random, which means that sometimes the mount works on boot, and sometimes it doesn't.

In my case, the nfs server should not have been active in the first place. That made the solution easy:

systemctl disable nfs-server.service

If you do need the nfs-server, you will need to break the dependency loop in a different way. I don't have the exact answer, but the general outline is (substitute the name of your mount unit etc, of course):

  • Find out the details of the service that systemd created, and turn it into a mount unit you control:

    systemctl cat home.mount >/etc/systemd/system/home.mount

  • Remove the entry in /etc/fstab . The home.mount file will take its place.

  • Edit the home.mount file as needed to remove the circular dependency. This is where I can't help because I didn't investigate in-depth where the issue was.

You can now test your mount:

systemctl daemon-reload
umount /home
mount -a

Instead of using mount -a, you should also be able to mount the directory with

systemctl start home.mount

Once you have tested the mount, reboot your system to see if the problem has gone away. Since the mounting sometimes worked by random chance, I would recommend checking /var/log/messages to ensure that there is no more circular dependency, and also rebooting not once but several times.

You must log in to answer this question.

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