[SOLVED] mount -a works but at boot CIFS mounts fail

jfabernathy · 2021-07-31 23:54:23

First some background. I have a new ASRock NUC 1165G7 which has an 11th gen Intel Core i7 with Iris GFX. It's been giving me a fit on video playback and I've tried different distros and different kernels.

I'm having good success so far with Archlinux with KDE Plasma. However, one of the things I must get working is mounting at boot my NAS via CIFS/SMB. I can do this in my sleep on *buntu. But I can't get it working on Arch. The first thing I had to do was add the vers=3.0 option. Apparently my Ubuntu 20.04 LTS NAS isn't using the default that Arch uses.

So after boot, the shares are not mounted and this is in my dmesg output.

[ 2.141055] CIFS: VFS: Error connecting to socket. Aborting operation.
[ 2.141057] CIFS: VFS: cifs_mount failed w/return code = -101
[ 2.141079] CIFS: Attempting to mount \\192.168.0.250\anonymous
[ 2.141100] CIFS: VFS: Error connecting to socket. Aborting operation.
[ 2.141102] CIFS: VFS: cifs_mount failed w/return code = -101

my fstab for networking is:

//192.168.0.250/public /mnt/public cifs defaults,user=jim,password=noway849,uid=jim,gid=users,dir_mode=0775,file_mode=0664,vers=3.0 0 0
//192.168.0.250/anonymous /mnt/anonymous cifs defaults,user=jim,password=noway849,uid=jim,gid=users,dir_mode=0775,file_mode=0664,vers=3.0 0 0
#

I'm assuming that cifs mounts are trying to be done prior to the networking being up. I would have thought that systemd would take care of this.

I installed archlinux using archinstall script and chose grub, NetworkManager, KDE, and took the basics.

System info is:

Operating System: Arch Linux
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2
Kernel Version: 5.13.6-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Memory: 15.0 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics

Last edited by jfabernathy (2021-08-20 21:20:35)

V1del · 2021-08-01 00:05:57

You need to enable NetworkManager-wait-online.service for this kind of automation to work properly.

Alternatively I find it much more stable/controllable to use a NetworkManager-dispatcher script, like described in https://wiki.archlinux.org/title/Samba# … c_mounting

jfabernathy · 2021-08-01 00:40:09

I checked and NetworkManager-wait-online.service is enabled and active. So not sure what is the problem.

I'll look at the alternative you suggested.

Thanks,

Fixxer · 2021-08-01 05:45:38

Add this in options section in /etc/fstab:

_netdev

OR

_netdev,nofail

Man mount:

_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).
nofail
Do not report errors for this device if it does not exist.

Last edited by Fixxer (2021-08-01 05:46:07)

seth · 2021-08-01 06:12:17

installed archlinux using archinstall scrip

Sanity check:

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

Personally preferred apporach to network mounts is "noauto,x-systemd.automount" - esp. if you're only gonna need the share somewhen later and hot eg. as you $HOME

Also NetworkManager-wait-online.service is broken by default:
https://bbs.archlinux.org/viewtopic.php … 0#p1948020
https://man.archlinux.org/man/extra/net … nline.1.en ("-s")

So if you're manually (or with your session only) connect to a wifi, nm-online considers you "online" as soon as NM started, regardless of the actual network state.
https://wiki.archlinux.org/title/Networ … et_on_boot

"networking that just works" - they never said how well, though…

jfabernathy · 2021-08-01 10:41:53

Interesting development. Since everything I tried with NetworkManager failed to mount my smb/cifs shares at boot, I did a new install using archinstall script and this time instead of selecting NetworkManaager, I selected the NIC that my cable is connected to.

So after install, I simply used the /etc/fstab statements that I use on ubuntu to mount my smb shares and it worked correctly on boot.

jfabernathy · 2021-08-13 02:11:08

I continue to play with this cifs networking issue using NetworkManager and have come to a working solution. My question is whether or not this is how I should be doing it anyway. In this test I didn't do anything with systemd for NetworkManager-wait-online. It's disabled by default.

I've been installing Arch with KDE on some laptops and and not adding any cifs mounts in fstab. I've been using NetworkManager since the laptops support both wired and WiFi, and can easily switch back and forth with NM.

In Dolphin File Manager I use the Network Place in the sidebar to attach to my share just typing in:

smb://192.168.0.250/anonymous.

Once I enter my user and password for the share and check remember password, I then can right click on the remote share and add it to Places and it's always there.

I have found that even after reboot, by the time I login the WiFi has connected and when I open Dolphin, the cifs share is there and I can click to any folder. I have not found this to fail. This is not something I could do with the mount of the cifs share in fstab.

This may not be the way you want to do a server, but for a desktop/laptop it seems to the easiest.

What is the consensus on this method?

Last edited by jfabernathy (2021-08-13 02:13:57)

V1del · 2021-08-13 06:39:55

There's no consensus, do what you want. FWIW which method did you use to "do this in your sleep on Ubuntu" ? They ultimately will largely have a similar SW stack that I doubt Ubuntu has some random magic to make a kernel level cifs mount in your fstab work better than it would on Arch.

In any case, I also use KDE's integrated SMB KIO on my laptop, primarily because doing it with CIFS and automount can lead to weird stalls on suspension wakeup/shutdown that can freeze the desktop for a while depending on which process is currently active on the thing. Just using a user level connection is much more forgivable. One problem with that approach (... though this should be solved with fuse-kio now, but haven't really looked into that yet) that the connection dolphin uses is built with KIO which is only really supported with KDE programs. But if you only access files directly with KDE tools and/or download files locally anyway this isn't going to be much of an issue

Technically a kernel mount should be "faster" but you're unlikely to notice that when your network speed will be the relevant bottleneck.

jfabernathy · 2021-08-13 10:06:56

V1del wrote:

... FWIW which method did you use to "do this in your sleep on Ubuntu" ? They ultimately will largely have a similar SW stack that I doubt Ubuntu has some random magic to make a kernel level cifs mount in your fstab work better than it would on Arch.

It's interesting that as I remember using *buntu versions I only did 2 things to get CIFS shares mounted on a client, mostly desktops. One was add the entries into /etc/fstab and the 2nd was to install cifs tools. All of the NetworkManager-wait-online stuff just worked out of the box. This surprising worked even with a system that suspends with no activity. I had a few cases where the server was rebooted after maintenance and the client needed to manually mount -a.

I have had cases where addition systemd services had to be added to a box running mythtv backend to implement a wait for ping type function because that backend software would not recover if a network tuner was not completely up before it ran. This eliminated a race condition.

I have seen issues that a client hangs up for 1.5 minutes waiting on a cifs share either booting or shutting down using the fstab method. But so far at least on a wired desktop and a few laptops the KDE SMB KIO method, as you call it, seems to work very well.

Thanks,

seth · 2021-08-13 12:14:39

All of the NetworkManager-wait-online stuff just worked out of the box.

This doesn't explain why, though - the wakeup could have been stalled or they removed the stupid -s flag from the wait-online.service (you can edit the service, https://wiki.archlinux.org/title/System … ided_units )
Or NM just didn't cut the connection for the suspend (at which point pretty much nothing will happen)

As for boots, the main question w/ NM is whether you allow global connections ( https://wiki.archlinux.org/title/Networ … et_on_boot )
And to repeat myslef: to not have the fstab network mounts stall the boot process waiting for the network to come up, "noauto,x-systemd.automount" them on demand only.

jfabernathy · 2021-08-13 12:38:50

And to repeat myslef: to not have the fstab network mounts stall the boot process waiting for the network to come up, "noauto,x-systemd.automount" them on demand only.

Thanks, I'll give "noauto,x-systemd.automount" some more testing. However, on my laptops the KDE KIO Dolphin cifs mounting is working very nicely.

EDIT: Can I assume that using no-auto,x-systemd.automount only works for systemd-networkd systems and not Network Manager systems???

Last edited by jfabernathy (2021-08-13 12:54:01)

V1del · 2021-08-13 13:03:39

that doesn't matter. automount only ensures that the actual mount is attempted when you actively access that path with something it doesn't have an inherent connection to which connection method you are using and is also valid for normal USB drives for example.

Last edited by V1del (2021-08-13 13:04:23)

jfabernathy · 2021-08-13 13:31:52

V1del wrote:

that doesn't matter. automount only ensures that the actual mount is attempted when you actively access that path with something it doesn't have an inherent connection to which connection method you are using and is also valid for normal USB drives for example.

Thanks for reiterating this approach. As a test I reinstalled Arch but Gnome 40 this time using archinstall script. I chose NetworkManager again.

After boot I edited fstab with:

//192.168.0.250/anonymous /mnt/anonymous cifs defaults,user=jim,password=br549,uid=jim,gid=users,dir_mode=0775,file_mode=0664,noauto,x-systemd.automount 0 0

On any reboot, clicking on /mnt/anonymous with Files app shows the folders without delay. This also works after I close the lip on the laptop, it sleeps, then reopen the lid. Seems to be really stable.

Thanks for the solution.

jfabernathy · 2021-08-13 15:28:17

Just an observation. I tested the "noauto,x-systemd.automount" use in fstab on a Archlinux KDE system and found that indeed on the first reference to a remote share folder it worked. i.e. ls /mnt/anonymous/den-pc-files

However, one small thing on the first use of Dolphin. If the focus had previously been on a local folder like Downloads, when you start Dolphin it shows a symbol under the Places toolbar entry for the share indicating unmounted. The first time you click it you get an error in Dolphin, but click again and the folder opens.

If I run any program that used a file in /mnt/anonymous .... it works without issue.

Arch Linux

#1 2021-07-31 23:54:23

[SOLVED] mount -a works but at boot CIFS mounts fail

#2 2021-08-01 00:05:57

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#3 2021-08-01 00:40:09

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#4 2021-08-01 05:45:38

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#5 2021-08-01 06:12:17

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#6 2021-08-01 10:41:53

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#7 2021-08-13 02:11:08

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#8 2021-08-13 06:39:55

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#9 2021-08-13 10:06:56

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#10 2021-08-13 12:14:39

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#11 2021-08-13 12:38:50

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#12 2021-08-13 13:03:39

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#13 2021-08-13 13:31:52

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

#14 2021-08-13 15:28:17

Re: [SOLVED] mount -a works but at boot CIFS mounts fail

Board footer