Hi,
I’m unable to find the cause of quite a long timeout on the systemd-networkd-wait-online service.
This timeout only appears when some CIFS shares are added to the /etc/fstab. Shares are in the /etc/fstab with the _netdev option.
The issue is the same when either LAN and/or WLAN is connected.
Commenting out these shares removes the timeout, so I know it’s related to those fstab entries, but I cannot seem to find the cause of this timeout.
Can you guru’s help me out 
Martien
That tells them to wait for the network to be fully available before trying to mount anything.
My advice would be to use a systemd-automount in /etc/fstab. That will mount the drive on access.
Something like this:
//servername/sharename /path/to/mount/share cifs x-systemd.automount,x-systemd.idle-timeout=1min,rw,uid=1000,gid=1000,credentials=/etc/samba/private/mycreds.cred,iocharset=utf8,vers=2.0 0 0
You don’t have to use a credential file. You can embed the credentials in the mount options but, I don’t recommend that.
Hi Dalto,
Tried multiple things in the mean time with your suggestion:
Weird though that the systemd-networkd-wait-online.service waits for that amount of time 
Still got some weird feeling about this, check the Samba page on Arch Wiki (Samba - ArchWiki for suggestions or idea’s too but no cigar unfortunately.
Did you just add that to your list of options or did you redo all your options to match what is needed for a systemd-automount?
This seems like a pretty questionable workaround.
Why not using one of those proposed solutions?
For clarifying the issue, you should first decide what exactly you want… 
Ain’t we all?
If you can accept your shares are mounted some time after you boot and not immediately to the 1st possible second, you may create a timer/service units pair to mount them a specified time after boot.
This is the difficult way, unless you are familiar with systemd units. Nevertheless, if you choose this way, you have to learn about systemd units, and this is really worth for the future.
The easy way is to disable the wait-online service, despite @dalto questions it
Maybe another easy way is to modify the existing service Exec= value, adding a parameter.
sudo systemctl edit systemd-networkd-wait-online.service
Write this in the editor at the top:
[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any
Then run systemctl daemon-reload or reboot.
For understanding the problem, you might want to read relevant man pages of those service units and upstream docs.
In short, the wait-online service waits for every network connection to complete, before succeeding. --any tells it to wait for only one connection.
It is a known issue and systemd gurus suggest that admins (Linux users, in our terms) should fix their connections/services, not disable wait-online, but they will not get angry if we do (my wording…).
https://systemd.io/NETWORK_ONLINE/
man systemd-networkd-wait-online
man NetworkManager-wait-online.service # the same issue for NM, man and service
systemctl cat NetworkManager-wait-online.service # they wrote info inside the service
Creating a service, as described in Samba might not be a bad idea, but the easy way is as above.
Just added the x-systemd.automount option (I left the _netdev option though).
Looks like the timeout is caused by systemd, because ALL network interfaces need to be online for systemd-networkd-wait-online.service to finish (or timeout on failure).
I suspect this is the base of the issue. Got loopback, ethernet, wifi and ‘virbr0’, but sometimes ethernet is not online.
Weird thing is that the --any option works on the system-networkd-wait-online.service but fails after 2 minutes, running the same services with ‘wlan0’ as the parameter exits without issue? Did not expect that to happen.
This is the default timeout for the service/command (when not specified), which seems to restart the check again.
IMHO, this is a cosmetic issue (the failed service), since it has a practical meaning only on boot (at least, as I understand it).
As I said, 1st find what you want and then modify/add relevant parameters.
If you need more than wlan (i.e. eth), add this with --interface=.
If you don’t, and only need wlan, use only this.
Disabling the service will not harm. It is only required, when you need it, for specific reasons.
Testing several scenarios, will ensure you what serves you better. OTOH, a disabled service with functionality that you prefer, sounds better to me than a failed service which creates issues (late boot). 
Mostly using this at home with a stable network, so decided indeed to disable the failing service. Might get back to it at a later stage (if it annoys me enough again 
)
Thanks for the suggestions!