fstab not mounting network drive but mount -a will

[rfemali3]

I have recently installed Bullseye and I have a network drive I would like it to mount on boot (an external drive attached to another machine running Mageia . So far, I can not get the drive to mount using fstab, but it will mount with no problems by manually running a mount -a or by using @reboot /bin/mount -a via crontab -e (it will not work as a /etc/crontab entry).

My fstab entry is as follows:

//MagOffice/MagExternal /mnt/MagExternal cifs _netdev,auto,uid=1000,credentials=/etc/samba/auth/MagOffice,iocharset=utf8,noperm,vers=3.0 0 0

I have tried it with vers=1 and vers=2, with and without _netdev, auto, noperm. I have also tried using x-systemd.automount and x-systemd.mount-timeout=x. I ahve also tried adding a sleep=x when trying to use the @reboot in /etc/crontab and crontab -e

dmesg | tail with just the fstab (no @reboot anywhere) is:

[    4.431214] FS-Cache: Netfs 'cifs' registered for caching
[    4.433890] Key type cifs.spnego registered
[    4.433893] Key type cifs.idmap registered
[    4.434069] CIFS: Attempting to mount //MagOffice/MagExternal
[    7.194490] e1000e 0000:00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    7.194581] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[    7.495246] kauditd_printk_skb: 12 callbacks suppressed
[    7.495248] audit: type=1400 audit(1682388335.137:23): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=576 comm="cups-browsed" capability=23  capname="sys_nice"
[    7.514277] CIFS: VFS: \\MagOffice Error -104 sending data on socket to server
[    7.514296] CIFS: VFS: cifs_mount failed w/return code = -104

dmesg | tail with a manual mount -a is:

[    4.395310] Key type cifs.spnego registered
[    4.395312] Key type cifs.idmap registered
[    4.395496] CIFS: Attempting to mount //MagOffice/MagExternal
[    7.113393] e1000e 0000:00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    7.113469] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[    7.449282] CIFS: VFS: \\MagOffice Error -104 sending data on socket to server
[    7.449309] CIFS: VFS: cifs_mount failed w/return code = -104
[    7.461895] kauditd_printk_skb: 12 callbacks suppressed
[    7.461898] audit: type=1400 audit(1682388788.104:23): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=585 comm="cups-browsed" capability=23  capname="sys_nice"
[   67.620941] CIFS: Attempting to mount //MagOffice/MagExternal

dmesg | tail with @reboot /bin/mount-a in crontab -e is:

[    4.315396] FS-Cache: Netfs 'cifs' registered for caching
[    4.317715] Key type cifs.spnego registered
[    4.317717] Key type cifs.idmap registered
[    4.317890] CIFS: Attempting to mount //MagOffice/MagExternal
[    6.994433] e1000e 0000:00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    6.994505] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[    7.396278] kauditd_printk_skb: 12 callbacks suppressed
[    7.396280] audit: type=1400 audit(1682390188.036:23): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=587 comm="cups-browsed" capability=23  capname="sys_nice"
[    7.407156] CIFS: VFS: cifs_mount failed w/return code = -112
[    7.425606] CIFS: Attempting to mount //MagOffice/MagExternal

I am perplexed as to why it will not auto mount with just the fstab entry as i thought a mount -a command just calls the fstab. Any insight would be greatly appreciated.

[sunrat]

Perhaps the network is not up when mount is attempted during boot. I recall there have been several similar recent topics.

[kent_dorfman766]

@Aki that would be my guess as well, and I'd add that the systemd way of dealing with this is to do the mount as a systemd unit file, using the after= line to make sure it's only executed once networking has been initialized. IOW, don't do it in fstab.

man 5 systemd.mount

[Aki]

Hello,

The error codes can be decoded using the errno command (from the moreutils [1] package).

During boot, in the kernel ring buffer, the error -104 is reported by the kernel for the first and second log:

Code: Select all

$ errno 104
ECONNRESET 104 Connection reset by peer 

Therefore, it should mean that the connection is reset by the remote samba server.

The other error you reported is -112 for the last log:

Code: Select all

$ errno 112
EHOSTDOWN 112 Host is down

In this case, the remote samba server seems to be down.

Probably, more debugging at kernel module level could be useful.

It could be caused a race condition between the local mount of the CIFS remote file system and the availability of the network connectivity to reach the remote samba server, as @sunrat and @kent_dorfman766 already pointed out.

Unfortunately, I was not able to replicate your issue in a test installation where both the client and server where running on two different instances of Debian Bookworm (while your are running Debian Bullseye on client side) and the _netdev option was used. In this test, if the samba server was not turned on, the mount error code was -113 (different error code from those you reported).

What is the samba server version you are using on the server running Mageia ? Have you checked the logs of the samba server (on Mageia) searching for clues ?

---
[1] https://packages.debian.org/bullseye/moreutils

[rfemali3]

@kent_dorfman766, @sunrat , and @Aki thanks for the replies! Samba version on the Mageia is 4.16.10. Host is down error is interesting as I have a 2 other machines attached to the same resource and can access the share with no issues. I am also suspicious of the race condition as I do not need a sleep or wait in the @reboot command and dmesg states NIC link is up. Wrong thinking on that?

Anyway, late work day today and probably tomorrow so I will have to take a look at the samba server logs over the weekend. Not sure why I did think to check that already. Thanks for the nudge, @Aki .

[Aki]

Hello,

I am also suspicious of the race condition [..] Wrong thinking on that?

In the first kernel log from kernel ring (system booting) :

Code: Select all

$ dmesg | tail
[    4.431214] FS-Cache: Netfs 'cifs' registered for caching
[    4.433890] Key type cifs.spnego registered
[    4.433893] Key type cifs.idmap registered
[    4.434069] CIFS: Attempting to mount //MagOffice/MagExternal
[    7.194490] e1000e 0000:00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    7.194581] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[    7.495246] kauditd_printk_skb: 12 callbacks suppressed
[    7.495248] audit: type=1400 audit(1682388335.137:23): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=576 comm="cups-browsed" capability=23  capname="sys_nice"
[    7.514277] CIFS: VFS: \\MagOffice Error -104 sending data on socket to server
[    7.514296] CIFS: VFS: cifs_mount failed w/return code = -104

you can see that the attempt to mount the remote share:

Code: Select all

[    4.434069] CIFS: Attempting to mount //MagOffice/MagExternal

is logged three seconds before the NIC link is logged as UP:

Code: Select all

[    7.194581] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready

and a fraction of a second after the cifs_mount failed is logged:

Code: Select all

[    7.514277] CIFS: VFS: \\MagOffice Error -104 sending data on socket to server
[    7.514296] CIFS: VFS: cifs_mount failed w/return code = -104

There are some oddities, anyway.

First of all, with the _netdev option [1] in the share definition of /etc/fstab this should not occur:

_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).

As @kent_dorfman766 pointed out in previous message, it could be enforced using systemd configuration [2], but it should not necessary in the first place, IIRC:

_netdev
Normally the file system type is used to determine if a mount is a "network mount", i.e. if it should only be started after the network is available. Using this option overrides this detection and specifies that the mount requires network.
Network mount units are ordered between remote-fs-pre.target and remote-fs.target, instead of local-fs-pre.target and local-fs.target. They also pull in network-online.target and are ordered after it and network.target.

Then, the CIFS mount attempt is logged very early in the boot process.

What is the installed init system ? You can check with:

Code: Select all

ls -la /sbin/init

How does your computer configure the network ? Are you using ifupdown, network-manager or other software ?

Can you double check your configuration in /etc/fstab for the samba network share and report it in a follow up message.

addendum: please, use code tag in messages to delimit code or logs (as in this message): see "Outputting code or fixed width data" at https://www.phpbb.com/community/help/bbcode.

---
[1] https://manpages.debian.org/bullseye/mount/mount.8.en.html
[2] https://manpages.debian.org/bullseye/systemd/systemd.mount.5.en.html

[wizard10000]

...do the mount as a systemd unit file
...IOW, don't do it in fstab.

Late to the party but I do systemd automounts in fstab and they work fine. Mine are all NFS shares but at least I don't have to create unit files

Part of my home server's fstab:

Code: Select all

# laptop drives
192.168.1.110:/	/media/laptop	nfs	_netdev,x-systemd.automount,x-systemd.mount-timeout=5	0	0
192.168.1.110:/media/external	/media/laptop-external	nfs	netdev,x-systemd.automount,x-systemd.mount-timeout=5	0	0

# tablet drive
192.168.1.120:/	/media/tablet	nfs	netdev,x-systemd.automount,x-systemd.mount-timeout=5	0	0

[Aki]

@rfemali3 : have you made any progress ?

[jkoegel]

Had a similar issue with CIFS mounts on a debian bookworm VMs. Other bookworm VMs, however, mounted CIFS shares at boot without problems.

Solved on that VM by adding "auto ens18" to /etc/network/interfaces

There was "allow-hotplug ens18" only - maybe a hotplug trigger is too late on the affected VMs?

[shanevapid]

I added the following conditions to /etc/fstab to make systemd wait for the network to be connected before trying to mount the drives.

• x-systemd.automount: Makes systemd handle the mounting as an on-demand process. The mount point will only be mounted when accessed.

• x-systemd.requires=network-online.target: Requires the network-online service.

• nofail: Prevent systemd from failing the boot process if the network drives are not available.

Make sure that the network-online.target service is enabled:

Code: Select all

sudo systemctl enable NetworkManager-wait-online.service

Here's what my entries look like:

Code: Select all

//10.0.0.1/ExtHD1 /mnt/ext1 cifs guest,uid=1000,gid=1000,file_mode=0777,dir_mode=0777,iocharset=utf8,nobrl,x-systemd.automount,x-systemd.requires=network-online.target,nofail 0 0
//10.0.0.2/ExtHD2 /mnt/ext2 cifs guest,uid=1000,gid=1000,file_mode=0777,dir_mode=0777,iocharset=utf8,nobrl,x-systemd.automount,x-systemd.requires=network-online.target,nofail 0 0