49

I'd like to know what is the exact mechanism (implementation) used to defer mounting until after network interface is up when one uses _netdev option in /etc/fstab?
Does systemd alter this behavior?
Also, what does delay_connect option to sshfs provide what _netdev does not?

From mount man page:

_netdev
The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system).

From sshfs man page:

-o delay_connect
delay connection to server

Improve this question
0

3 Answers 3

Reset to default
45

From man systemd.mount for version 231 of systemd:

Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.

Improve this answer
4
  • Awsome! No idea why this answer hasn't been up-voted yet.
    – Valentin Bajrami
    Mar 7, 2017 at 21:53
  • it doesn't work in debian stretch.
    – Paolo Benvenuto
    Mar 11, 2020 at 21:47
  • This doesn't explain why an fstab definition without _netdev fails not only at boot but also later at run time (with mount -a), but succeeds when this flag is added.
    – Mark Jeronimus
    May 23, 2022 at 13:31
  • Does this work on Mac?
    – a06e
    Nov 11, 2022 at 7:20
37

SysV Init

The /etc/init.d/mountall.sh init script mounts local filesystems only:

mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev

Other filesystems are mounted by separate init scripts, like for example /etc/init.d/mountnfs.sh, which declare (via LSB headers) their dependency on $network. Thus these get scheduled later, after the network is brought up, while mountall.sh can run much earlier.

systemd

Local mount units are pulled in by local-fs.target, remote ones by remote-fs.target. systemd-fstab-generator scans /etc/fstab, generates mount units and assigns these to the above targets based on conditions similar to the above.

delay_connect

This option means that sshfs will not initiate the SSH connection to the remote server at mount time, but will only do so on the first filesystem operation actually requiring it. This delays error reporting, but might be a useful workaround in some cases, for example if your init system hasn't got enough information to order the mount operation correctly. "The network" being "up" is a rather loose term, and even though one can add arbitrary extra dependencies to mount units that doesn't help if the trigger event is not part of the bootup transaction (in systemd parlance).

Improve this answer
5
  • So, you are saying that _netdev is not meant to be an argument passed to the process which performs mount (and which is specific to the type of mount like ext4/btrfs/cifs/fuse) but is meant to be read by other processes/scripts which based upon this flag decide when during the boot process these mounts should be executed. Yes? If so then I suspect this is the reason why this argument starts with underscore so that to differentiate it from other formal arguments.
    – Piotr Dobrogost
    May 12, 2016 at 12:19
  • Yes. If you pass the _netdev option to the mount command, it will be visible in /proc/mounts but have no other effect.
    – Ferenc Wágner
    May 12, 2016 at 14:07
  • 2
    Bonus question; is this documented somewhere?
    – Piotr Dobrogost
    May 12, 2016 at 14:41
  • 1
    The mount manual contains: "FILESYSTEM-INDEPENDENT MOUNT OPTIONS — Some of these options are only useful when they appear in the /etc/fstab file." Well, _netdev (documented somewhat later) is a fine example for this.
    – Ferenc Wágner
    May 12, 2016 at 15:04
  • 2
    The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. – bugzilla.redhat.com/show_bug.cgi?id=607309#c4
    – Piotr Dobrogost
    May 23, 2016 at 8:01
2

Upstart/Udev

For upstart and/or udev based systems this is slightly different.

It seems udev will still try to mount the NFS filesystems and netfs is a safety net for when that fails.

Please correct me if I'm wrong. either way, this answer is only relevant for some recent legacy systems (Ubuntu 14.04 LTS, RHEL6).

Improve this answer

You must log in to answer this question.

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