Cifs mount failing at boot but working later

adrianmay · 2019-05-06 08:00:16

Hi All,

I have two samba shares served up by an off-the-shelf docker container like this:

docker run --name=samba -d \
--net mydockernet \
--ip 10.60.0.90 \
-v /mnt/mag/docker/volumes/torrents/completed:/torrents \
-v /mnt/mag/docker/volumes/pics/new:/newpics \
-p 139:139 -p 145:145 \
-p 137:137/udp -p 138:138/udp \
--restart unless-stopped \
dperson/samba \
-n \
-s "torrents;/torrents" \
-s "newpics;/newpics;;no"

And the Arch client can connect with systemd like this:

::::::::::::::
mnt-newpics.mount
::::::::::::::
[Unit]
  Description=cifs mount script
#  After=remote-fs-pre.target
#  Wants=remote-fs-pre.target
  Requires=network-online.target
  After=network-online.service

[Mount]
  What=//10.60.0.90/newpics
  Where=/mnt/newpics
  Options=username=guest,password=,noperm,vers=3.0
  Type=cifs

[Install]
  WantedBy=multi-user.target
::::::::::::::
mnt-torrents.mount
::::::::::::::
[Unit]
  Description=cifs mount script
#  After=remote-fs-pre.target
#  Wants=remote-fs-pre.target
  Requires=network-online.target
  After=network-online.service

[Mount]
  What=//10.60.0.90/torrents
  Where=/mnt/torrents
  Options=username=guest,password=,ro,vers=3.0
  Type=cifs

[Install]
  WantedBy=multi-user.target

or fstab like this:

//10.60.0.90/newpics /mnt/newpics cifs username=guest,password=,noperm,vers=3.0 0 0 
//10.60.0.90/torrents /mnt/torrents cifs guest,ro,vers=3.0 0 0

Either way it works fine if I'm already booted, but not as part of the boot process. The systemd way leaves no trace in journalctl -xe and the fstab way leaves:

CIFS: Attempting to mount //10.60.0.90/torrents
CIFS VFS: Error connecting to socket. Aborting operation.
CIFS VFS: cifs_mount failed w/return code = -2
CIFS: Attempting to mount //10.60.0.90/newpics
CIFS VFS: Error connecting to socket. Aborting operation.
CIFS VFS: cifs_mount failed w/return code = -2

in dmesg.

Any help much appreciated.

adrianmay · 2019-05-07 20:03:36

Hey, slow down, don't all shout at once ;-)

WorMzy · 2019-05-07 20:23:41

Please don't bump.

https://wiki.archlinux.org/index.php/Co … ct#Bumping

V1del · 2019-05-07 22:06:40

Which network-online.target provider are you using/do you have enabled?

seth · 2019-05-08 06:58:14

fstab: https://wiki.archlinux.org/index.php/Fs … filesystem

Other than that, you probably also wanna wait for docker to be up and running?

adrianmay · 2019-05-10 10:38:10

Oh hi. Sorry for the silence.

> Which network-online.target provider are you using/do you have enabled?
I don't understand the question, which probably means it's the installation default.

> wait for docker to be up and running?
It's on a different box and runs continuously.

V1del · 2019-05-10 10:48:27

The network-online target the mount unit depends on will not be invoked if you haven't defined a handler for it. Which is why the "systemd way" doesn't show up (you are never invoking an online target so the unit is correctly never attempted to be mounted) and the fstab way will try and fail before the network is up. How are you connecting to the network? See the note in https://wiki.archlinux.org/index.php/Sa … c_mounting

Alternatively do it the way the wiki suggests in seths link, where a mount attempt will only be made when you actively access the device, which will presumably happen after the connection has established.

Last edited by V1del (2019-05-10 10:54:19)

adrianmay · 2019-05-10 13:08:32

So are you saying that I should take out those dependencies on network-online.target and simply trust that mounts like that already know what to wait for, and also enable systemd-networkd-wait-online.service, and then it should work?
Update: I tried that but it still doesn't mount.
I suppose I could resort to mounting on demand but I'd rather they were there from the outset

Last edited by adrianmay (2019-05-10 14:19:24)

V1del · 2019-05-10 14:41:46

No you should keep the dependencies on network-online.target (and be consequent here, one of the two is network-online.service instead, use target everywhere) but enable systemd-networkd-wait-online.service in addition. systemd-networkd-wait-online service will bring up, and thus start any units waiting on network-online.target

Also, you should of course also enable the mount unit regardless for it to be even considered.

FWIW you might want to post

systemctl list-unit-files --state=enabled
systemctl list-unit-files --type=mount

Last edited by V1del (2019-05-10 15:03:26)

adrianmay · 2019-05-10 15:10:24

So I corrected that stuff (including having network-online.target everywhere) but it still ain't working.

$ journalctl -u mnt-torrents.mount
...
...
May 10 16:00:47 blackmail systemd[1]: Mounting cifs mount script...
May 10 16:00:47 blackmail mount[753]: mount error(2): No such file or directory
May 10 16:00:47 blackmail mount[753]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
May 10 16:00:47 blackmail systemd[1]: mnt-torrents.mount: Mount process exited, code=exited, status=32/n/a
May 10 16:00:47 blackmail systemd[1]: mnt-torrents.mount: Failed with result 'exit-code'.
May 10 16:00:47 blackmail systemd[1]: Failed to mount cifs mount script.

$ systemctl list-unit-files --state=enabled
UNIT FILE                            STATE  
mnt-newpics.mount                    enabled
mnt-torrents.mount                   enabled
org.cups.cupsd.path                  enabled
autovt@.service                      enabled
getty@.service                       enabled
lm_sensors.service                   enabled
netctl@wifi.service                  enabled
org.cups.cupsd.service               enabled
sshd.service                         enabled
systemd-networkd-wait-online.service enabled
systemd-timesyncd.service            enabled
org.cups.cupsd.socket                enabled
remote-fs.target                     enabled
Deadbattery.timer                    enabled

14 unit files listed.

$ systemctl list-unit-files --type=mount
UNIT FILE                     STATE    
-.mount                       generated
dev-hugepages.mount           static   
dev-mqueue.mount              static   
home.mount                    generated
mnt-newpics.mount             enabled  
mnt-torrents.mount            enabled  
proc-fs-nfsd.mount            static   
proc-sys-fs-binfmt_misc.mount static   
sys-fs-fuse-connections.mount static   
sys-kernel-config.mount       static   
sys-kernel-debug.mount        static   
tmp.mount                     static   
var-lib-machines.mount        static   
var-lib-nfs-rpc_pipefs.mount  static   

14 unit files listed.

V1del · 2019-05-10 15:31:49

As you seem to use netctl you will want to disable systemd-networkd-wait-online.service and instead enable netctl-wait-online.service (these are always network daemon dependant)

However the error you are receiving now points to an issue in the .mount unit though I'm not entirely sure where if it indeed works after a connection is established.

adrianmay · 2019-05-10 17:00:05

Yippee!

Swapping systemd-networkd-wait-online.service for netctl-wait-online.service fixed it! Thanks!

Is this a doc error on https://wiki.archlinux.org/index.php/Sa … c_mounting ?

Arch Linux

#1 2019-05-06 08:00:16

Cifs mount failing at boot but working later

#2 2019-05-07 20:03:36

Re: Cifs mount failing at boot but working later

#3 2019-05-07 20:23:41

Re: Cifs mount failing at boot but working later

#4 2019-05-07 22:06:40

Re: Cifs mount failing at boot but working later

#5 2019-05-08 06:58:14

Re: Cifs mount failing at boot but working later

#6 2019-05-10 10:38:10

Re: Cifs mount failing at boot but working later

#7 2019-05-10 10:48:27

Re: Cifs mount failing at boot but working later

#8 2019-05-10 13:08:32

Re: Cifs mount failing at boot but working later

#9 2019-05-10 14:41:46

Re: Cifs mount failing at boot but working later

#10 2019-05-10 15:10:24

Re: Cifs mount failing at boot but working later

#11 2019-05-10 15:31:49

Re: Cifs mount failing at boot but working later

#12 2019-05-10 17:00:05

Re: Cifs mount failing at boot but working later

Board footer