NFS not mounting at boot but working with "mount -a"

[NinthWave]

So I have been skimming the internet and I can't find my answer:

I have Debian VM under Proxmox.
I want to mount a share at boot but it fails. with messages:
« Failed to mount... »
» Dependency failed for Remote File Systems"


After boot, using

Code: Select all

mount -a

it will mount just fine

/etc/fstab

Code: Select all

10.0.0.6:/mnt/Bassin/Media/Musique      /var/lib/docker/volumes/assetupnp_stack_media/_data     nfs     _netdev 0       0

Tried this:
/etc/systemd/system/systemd-networkd-wait-online.service.d

Code: Select all

[Service]
Type=oneshot
ExecStart=/lib/systemd/systemd-networkd-wait-online --interface=ens19

journalctl -b (excerpt)

Code: Select all

Jan 03 14:01:27 debian mount[291]: mount.nfs: Network is unreachable
Jan 03 14:01:27 debian systemd[1]: var-lib-docker-volumes-assetupnp_stack_media-_data.mount: Mount process exited, code=exited, status>
Jan 03 14:01:27 debian systemd[1]: var-lib-docker-volumes-assetupnp_stack_media-_data.mount: Failed with result 'exit-code'.
Jan 03 14:01:27 debian systemd[1]: Failed to mount /var/lib/docker/volumes/assetupnp_stack_media/_data.
Jan 03 14:01:27 debian systemd[1]: Dependency failed for Remote File Systems.
Jan 03 14:01:27 debian systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.

I can see the network is unreachable at the mount try.

I am at loss

[EDIT 19h EST]
More info

Code: Select all

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet dhcp

# TRUNK
allow-hotplug ens19
iface ens19 inet dhcp

Journlactl -b
https://pastebin.pl/view/12c60a46

[Aki]

Hi,
See viewtopic.php?t=138716

[NinthWave]

Hi,
See viewtopic.php?t=138716

I did dis

Code: Select all

[Unit]
Description = Mount NFS Share
After = systemd-network-wait-online.service

[Mount]
What=10.0.0.6:/mnt/Bassin/Media/Musique
Where=/var/lib/docker/volumes/assetupnp_stack_media/_data
Type=nfs
Options=defaults
# Uncomment the below if your server is real slow
TimeoutSec=10

[Install]
WantedBy=multi-user.target

And this

var-lib-docker-volumes-assetupnp_stack_media-_data.automount

Code: Select all

[Unit]
Description = Automount NFS Share

[Automount]
Where=/var/lib/docker/volumes/assetupnp_stack_media/_data
Type=nfs
TimeoutIdleSec=10

[Install]
WantedBy=multi-user.target

following this: https://wiki.archlinux.org/title/systemd#Drop-in_files
where I am pretty sure that my install is not using networkmanager,

Code: Select all

root@debian:/etc/systemd/system# systemctl is-enabled NetworkManager-wait-online.service
Failed to get unit file state for NetworkManager-wait-online.service: No such file or directory

Are my 2 files "kosher" now ?

Is the ".automount" also necessary ?



I tried a lot of things so now I am worried that differents solutions I tried will eventually collide.

Network management is pretty confusing.

[oswaldkelso]

Funnily I was researching trying to run a NFS server this morning.

I think you're on the right track with the timing but know nothing about docker.

I came across this
https://stealthbits.com/blog/create-mou ... tos-linux/

It seems there is a delay built in to NFS for data protection and you may get a fail message if the mount is attempted to quickly. Or the drive is a little slow to spin up.

Without docker I believe this does it but no idea about systemd or docker and how that effects things, but it might point you in the right direction.

/etc/fstab opps Edit that should be /etc/exports

Code: Select all

/nfs_example		192.168.1.0/24(rw,sync,no_subtree_check)

[Aki]

Hello,

I am pretty sure that my install is not using networkmanager,

Code: Select all

root@debian:/etc/systemd/system# systemctl is-enabled NetworkManager-wait-online.service
Failed to get unit file state for NetworkManager-wait-online.service: No such file or directory

Are my 2 files "kosher" now ?
Is the ".automount" also necessary ?
I tried a lot of things so now I am worried that differents solutions I tried will eventually collide.
Network management is pretty confusing.

Your installation does not use NetworkManager, but it relies on the package ifupdown to configure network interfaces: this is a common configuration for servers.

I suppose that the mount of the remote network file system (nfs share) fails because it is triggered before the network interfaces configuration is completed for the interface used by the mountpoint (journalctl_nfs.log is the names I used for your system log):

Code: Select all

grep -e "network\|nfs\|ifup\|mount" journalctl_nfs.log 
Jan 03 14:01:26 debian systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
Jan 03 14:01:26 debian systemd[1]: Starting Remount Root and Kernel File Systems...
Jan 03 14:01:26 debian kernel: EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
Jan 03 14:01:26 debian systemd[1]: Finished Remount Root and Kernel File Systems.
Jan 03 14:01:26 debian systemd[1]: Starting Helper to synchronize boot up for ifupdown...
Jan 03 14:01:26 debian systemd[1]: Finished Helper to synchronize boot up for ifupdown.
Jan 03 14:01:26 debian systemd[1]: nfs-config.service: Succeeded.
Jan 03 14:01:26 debian systemd[1]: Starting Raise network interfaces...
Jan 03 14:01:26 debian systemd[1]: Finished Raise network interfaces.
Jan 03 14:01:27 debian kernel: FS-Cache: Netfs 'nfs' registered for caching
Jan 03 14:01:27 debian mount[291]: mount.nfs: Network is unreachable
Jan 03 14:01:27 debian systemd[1]: var-lib-docker-volumes-assetupnp_stack_media-_data.mount: Mount process exited, code=exited, status=32/n/a
Jan 03 14:01:27 debian systemd[1]: var-lib-docker-volumes-assetupnp_stack_media-_data.mount: Failed with result 'exit-code'.
Jan 03 14:01:27 debian systemd[1]: Failed to mount /var/lib/docker/volumes/assetupnp_stack_media/_data.
Jan 03 14:01:27 debian systemd[1]: Found device Virtio network device.
Jan 03 14:01:27 debian systemd[1]: Started ifup for ens19.
Jan 03 14:01:27 debian systemd[1]: Found device Virtio network device.
Jan 03 14:01:27 debian systemd[1]: Started ifup for ens18.
[..]

As you can see, some network interfaces are started after the attempt to mount the network file system.

The operating system already has some options to configure dependency of network mounts in /etc/fstab, for examples see https://wiki.archlinux.org/title/fstab# ... ile_system (the _netdev option, for example).

Therefore, if the aforementioned options work, you don't need to create any systemd configuration files (and they should be removed if they are not required).

Hope that helps.

[NinthWave]

I suppose that the mount of the remote network file system (nfs share) fails because it is triggered before the network interfaces configuration is completed for the interface used by the mountpoint
[...]
As you can see, some network interfaces are started after the attempt to mount the network file system.

The operating system already has some options to configure dependency of network mounts in /etc/fstab, for examples see https://wiki.archlinux.org/title/fstab# ... ile_system (the _netdev option, for example).

Therefore, if the aforementioned options work, you don't need to create any systemd configuration files (and they should be removed if they are not required).

Hope that helps.

In my original post I did use _netdev option in the /etc/fstab without success.
Hence why I resorted to systemd.

If you believe some other option may work for /etc/fstam, I am open to it because it's easier that naming a .mount file. I have few other mounts for my NAS.

[Aki]

Hello,

In my original post I did use _netdev option in the /etc/fstab without success. Hence why I resorted to systemd. If you believe some other option may work for /etc/fstam, I am open to it because it's easier that naming a .mount file.

The network interface "ens19" looks like connected to the nfs server (according the systemd script service you tried in the first post).

It appears that the NFS mount attempt (from /etc/fstat) preempts the ens19 network interface configuration by a few seconds (according to the syslog).

You could try to configure a 10 seconds delay as mount point option in /etc/fstab; for example, using your the fstab entry of your first post:

Code: Select all

10.0.0.6:/mnt/Bassin/Media/Musique      /var/lib/docker/volumes/assetupnp_stack_media/_data     nfs    x-systemd.mount-timeout=10,_netdev       0

[kent_dorfman766]

You could try to configure a 10 seconds delay as mount point option in /etc/fstab; for example, using your the fstab entry of your first post:

Adding manual delays is a hack that is ill advised. You need to understand the systemd startup tree and make sure the mounts are being done after all required dependencies, and that if they themselves are prerequisites then other units need to be registered as After=

[Jason123]

I met exactly the same problem as yours. Also a debian server without gui above a pve. Here is the reason and solution.
The default network manager for debian server is `ifupdown`, with fundemantal functions and dhcp problem at boot time.
1. Install NetworkManager by `sudo apt install network-manager`.
2. Enable NetworkManager-wait-online service by `sudo systemctl enable NetworkManager-wait-online.service`.
3. the native configuration in `/etc/fstab` will work as expected.