A start job is running for Wait for Network to be Configured (35s / no limit)" -- no wifi network connection or samba network drives loaded during boot -- systemd-networkd problem

Issues & Assistance
1

A few days ago I did an update using the built in Garuda Octopi system. Now my local network samba shares are not being loaded via systemd at boot time (the service units *.automount and *.mount). I tracked it down (I think!) to a boot error which I can't find an answer to. Early in the /var/log/boot.log record I get the message:

Failed to start systemd-guest-user.service

When logged into a kde plasma session terminal I do:
status systemd-guest-user.service

....and get the following output:

`
× systemd-guest-user.service
Loaded: loaded (/usr/lib/systemd/system/systemd-guest-user.service; static)
Active: failed (Result: exit-code) since Wed 2022-01-12 11:01:15 NZDT; 34min ago
Main PID: 621 (code=exited, status=5)
CPU: 13ms

Jan 12 11:01:15 hpelitebook850g2 systemd[1]: Starting systemd-guest-user.service...
Jan 12 11:01:15 hpelitebook850g2 usermod[618]: usermod: no changes
Jan 12 11:01:15 hpelitebook850g2 chsh[619]: chsh: Shell not changed.
Jan 12 11:01:15 hpelitebook850g2 chsh[619]: Changing shell for guest.
Jan 12 11:01:15 hpelitebook850g2 passwd[621]: passwd: existing lock file /etc/shadow.lock without a PID
Jan 12 11:01:15 hpelitebook850g2 passwd[621]: passwd: cannot lock /etc/shadow; try again later.
Jan 12 11:01:15 hpelitebook850g2 systemd[1]: systemd-guest-user.service: Main process exited, code=exited, status=5/NOTINSTAL>
Jan 12 11:01:15 hpelitebook850g2 systemd[1]: systemd-guest-user.service: Failed with result 'exit-code'.
Jan 12 11:01:15 hpelitebook850g2 systemd[1]: Failed to start systemd-guest-user.service.
`

So far I have tried reinstalling the package systemd-guest-user from chaotic aur, which didn't help - not fixed.

I am able to manually load the samba drive via the following:
systemctl start home-rob-Network-Pi4Drive.mount && systemctl enable home-rob-Network-Pi4Drive.automount

Anyone have any ideas about how to fix this systemd-guest-user.service problem?

2

Unless you are logging in as guest, this is probably unrelated to your samba issue.

1 Like
3

You're absolutely right, I don't think systemd-guest-user.service is directly related to the samba problem. I am suspecting that this is a systemd service units system issue, as the samba *.mount and *.automount systemd units are not being loaded at boot, just like the systemd-guest-user.service unit is failing to load at boot. Surely the systemd-guest-user.service not loading is indicative/symptomatic of the samba units not loading?

4

Maybe try removing the guest account and the reinstall it after rebooting.

5

Thanks. I actually don't have a guest account but I presume you mean remove the Garuda chaotic aur package systemd-guest-user? Yup I'll give it a try right now and report back.

1 Like
6

If you're not using a guest account you might as well remove the guest package and leave it that way if it helps.

2 Likes
7

guest package removed, the systemd error no longer pops up. No dice on the samba issue though. I had another look through the /var/log/boot.log and towards the end I have:

[e[0;1;31mFAILEDe[0m] Failed to mount e[0;1;39m1TB Pi4 drive (Samba 10.14.0.1 rw for user rob uid=1000)e[0m.
See 'systemctl status home-rob-Network-Pi4Drive.mount' for details.

doing systemctl status home-rob-Network-Pi4Drive.mount outputs this:

× home-rob-Network-Pi4Drive.mount - 1TB Pi4 drive (Samba 10.14.0.1 rw for user rob uid=1000)
Loaded: loaded (/etc/systemd/system/home-rob-Network-Pi4Drive.mount; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2022-01-12 19:28:36 NZDT; 11min ago
TriggeredBy: × home-rob-Network-Pi4Drive.automount
Where: /home/rob/Network/Pi4Drive
What: //10.14.0.1/1TB-Drive/
CPU: 5ms

Jan 12 19:28:36 hpelitebook850g2 systemd[1]: Mounting 1TB Pi4 drive (Samba 10.14.0.1 rw for user rob uid=1000)...
Jan 12 19:28:36 hpelitebook850g2 systemd[1]: home-rob-Network-Pi4Drive.mount: Mount process exited, code=exited, status=32/n/a
Jan 12 19:28:36 hpelitebook850g2 mount[6641]: mount error(101): Network is unreachable
Jan 12 19:28:36 hpelitebook850g2 mount[6641]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Jan 12 19:28:36 hpelitebook850g2 systemd[1]: home-rob-Network-Pi4Drive.mount: Failed with result 'exit-code'.
Jan 12 19:28:36 hpelitebook850g2 systemd[1]: Failed to mount 1TB Pi4 drive (Samba 10.14.0.1 rw for user rob uid=1000).
Jan 12 19:28:36 hpelitebook850g2 systemd[1]: home-rob-Network-Pi4Drive.mount: Start request repeated too quickly.
Jan 12 19:28:36 hpelitebook850g2 systemd[1]: home-rob-Network-Pi4Drive.mount: Failed with result 'exit-code'.
Jan 12 19:28:36 hpelitebook850g2 systemd[1]: Failed to mount 1TB Pi4 drive (Samba 10.14.0.1 rw for user rob uid=1000).

This samba drama is happening on my HP Laptop which relies on wifi being up to connect to the samba pi4drive. My other machine which had the same recent updates has no problems with the samba connectivity. Could it be that the systemd system is trying the *.mount and *.automount units in the wrong order - ie prior to the wifi connection being up?

8

Read the extensive Samba info on the Archwiki:

https://wiki.archlinux.org/title/samba#As_mount_entry

9

I did that when I set it up. The samba worked flawlessly (up until early January a few days ago) using systemd mount and automount for more than a year, and it still works on my other machine with exactly the same setup except that machine is wired rather than wireless. Now, with what I thought would be a routine system update, something is broken. I set samba share up by the book according to the archwiki and other documents at the time. I haven't changed anything with the samba setup, the only thing that has changed is a Garuda Linux system update. I am unsure of how re-reading the samba archwiki is going to help when I followed it to the letter to get a perfectly working system originally?

....and - if you read my original post you will see that samba actually works because I can manually issue systemctl start commands once the system is up, so there can't be anything wrong with how I've set up the systemd unit files for the samba share (according to the archwiki). The problem is with systemd after the January Garuda update, and not with samba (ie systmemd not loading the samba mount and automount units at the right time as is plain in the boot log).

10

I hate Samba, it sucks (I despise all things Microsoft & I will not use it).

I usually use NFS, (it is usually rock solid), but I have experienced the odd issue such as you are now. It could be a breakage caused by a samba or kernel update (among other things).

The times I experienced similar as you described sometimes a kernel change would help, (try the LTS kernel first). Even though it shouldn't matter, sometimes I found the network broke with a mount unit, but I could get it to work using an fstab entry (and vice versa).

I

11

I appreciate your help but Microsoft hate at this point is not really that useful. Besides, samba is not Microsoft. Samba is the (robust) *nix implementation of the SMB protocol, originally developed by Barry Feigenbaum at IBM. SMB just happens to be be the system Microsoft adopted extensively, and therefore it is the most useful protocol for anyone considering network shares as it is the defacto main standard. Try doing an NFS share that works well with all apple, windows, android and linux machines on the network - I'll buy you a beer if you can achieve it.

1 Like
12

That’s never going to happen, because you couldn’t pay me to use those OS’s. :wink:

My dislike for Samba is not simply because it is an implementation designed to work with Windows, it is because it is often a royal pain to setup in Linux and is very breakage prone. Many times Samba updates break your configuration completely. If Samba were reliable, I probably never would have switched to NFS in the first place.

My viewpoint aside, I rarely delve into Samba support cases anymore as I haven’t used it in years. I simply thought I’d offer a few tips that might prove helpful.

Best of luck with your Samba issue.

13

Thanks. Though as pointed out, samba does not appear to be not broken here as it loads perfectly fine manually using systemctl . Instead, the systemd units system looks to be the problem as it is not loading the mount and automount units correctly at boot/login. I just hope I don't end up having to hose down the laptop with a new Garuda install just to fix a systemd issue.

14

Not to beat a dead horse here. but if Samba isn’t starting on its own, (for whatever reason) that qualifies as broken in my book.

You could try adding a three second delay in the systemd units to see if that helps.

Posting the ouputs from the commands below might be useful:

systemctl list-unit-files --state=failed --no-pager

systemctl list-units -l --no-pager| grep -iE '(net|conn|dhcp|dns)' |grep -viE "(fuse|time)" 

systemctl status NetworkManager-wait-online.service

systemd-delta --no-pager 

systemctl list-units --type mount | grep "/" 

journalctl -b -p3 --no-pager --no-hostname

You may also want to read about the use of NM dispatcher scripts:

https://wiki.archlinux.org/index.php/NetworkManager#Network_services_with_NetworkManager_dispatcher

15

Thanks. After hours of trial and error, googling and fiddling with systemd I discovered the following:

  • The samba mount and automount unit files not loading was a a problem with wifi connectivity not being established at boot time (probably brought about by the system update I did early Jan), therefore all systemd could do was throw errors and fail the mount and automount units (confirmed with systemctl status).
  • I can't be precise on details, but I understand that boot-time wifi connection is established via systemd-networkd.service, which itself relies upon wpa_supplicant (default in Garuda), or the newer iwd, to make boot-time network connections. It appears that wpa_supplicant is also the backend to networkmanager in Garuda, but it can operate independently of networkmanager, such as it does with systemd-networkd interoperability.

How did I figure all this out and fix this issue? Googling led me to believe that there was a problem with wpa_supplicant and the way it was set up in relation to systemd-networkd. Since iwd looks like it will be replacing wpa_supplicant soon anyway, I decided to give that a try so I uninstalled networkmanager and replaced it with a fresh install of networkmanager-iwd. Short end story to the saga that ensued after that is that I couldn't get iwd working properly so I reverted to the networkmanager with the wpa_supplicant backend. To my surprise, booting worked properly after that, with wifi network being established during boot by systemd-networkd & wpa_supplicant, and my samba share drive being connected to automatically as it should (via the systemd unit files mount and automount).

I haven't learned anything here really, other than getting new generalised understanding around how systemd establishes network connectivity during boot prior to anyone logging into the machine. That, and I just got lucky it seems. The reinstall of networkmanager back to the default backend of wpa_supplicant must have corrected whatever went wrong when I did the system update a few days ago. Fixed.

2 Likes
16

Glad you found your fix, and thanks for reporting your findings.

Just FYI, the networkmanager-iwd package often doesn't seem to work properly for many that test it out.

However, you can manually add iwd yourself, (if you want to test out iwd).

How to replace wpa_supplicant with iwd:

With a text editor, create the required iwd configuration file for Network Manager:

/etc/NetworkManager/conf.d/wifi_backend.conf

With the following contents:

[device]
wifi.backend=iwd

Then, save the configuration file.

Next, Install and enable iwd, and mask wpa_supplicant:

sudo pacman -Syu iwd 
systemctl stop NetworkManager
systemctl stop wpa_supplicant
systemctl mask wpa_supplicant
systemctl enable --now iwd.service
systemctl daemon-reload
systemctl start NetworkManager

A restart may be required afterwards.

How to revert your changes and restore wpa_supplicant:

To restore wpa_supplicant to usage, comment out the lines you created in /etc/NetworkManager/conf.d/wifi_backend.conf , as so:

#[device]
#wifi.backend=iwd

Save the changes, then execute:

systemctl stop NetworkManager
systemctl disable --now iwd.service
systemctl mask iwd.service
systemctl unmask wpa_supplicant
systemctl enable --now wpa_supplicant
systemctl daemon-reload 
systemctl start NetworkManager

A restart may be required afterwards.

Just thought I'd post that info, in case you might need it in the future.

5 Likes
17

Thanks @tbg , that's really useful as I expect at some point in the near future I'll be exploring iwd again; I've saved your recipe to my useful pointers file :slight_smile: .

I would like to rename this posting to something more meaningful so others might find it, now that I know what the real issue was. I think I need admin privileges to do that though as I couldn't find an option open to me for that. Thinking I'd rename this to something like (?):

"boot delay message "A start job is running for Wait for Network to be Configured (35s / no limit)" -- no wifi network connection or samba network drives loaded during boot -- systemd-networkd problem"

Thanks again

1 Like
18

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.