30

I'm trying to mount a CIFS device after the system boots (using systemd), but the system tries to mount the system before the network is established, so it fails.

After logging into the system I can mount it without any problem, using sudo mount -a.

How can I tell my Arch (arm) to wait until the network is available?

1

6 Answers 6

42

Adding _netdev to the mount options in /etc/fstab might be sufficient.

Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.

Additionally systemd supports explicit order dependencies between mount entries and other units: Adding x-systemd.after=network-online.target to the mount options might work if _netdev is not enough.

See the systemd mount unit documentation for more details.

3
  • 1
    the _netdev section did not work for me BUT it was left and the x-systemd.after=network-online.target did on nfsv4 mounts, this was verifed on U16.04.6 vm
    – ssvegeta96
    Commented Dec 23, 2019 at 19:16
  • @ssvegeta96 yeah, i have never in my life seen that _netdev works on systemd. they just don't care enough. (not to mention that needing any of that is a regression compared to classic unix which simply sorted the fstab from local to non-local) Commented Aug 29, 2022 at 1:11
  • 1
    careful: having nofail disables the automatic addition of x-systemd.after... targets (cf same doc page), so you have to add them explicitly Commented Nov 3, 2023 at 16:10
9

Add _netdev to the /etc/fstab entries in question. From the manpages for `mount(8)':

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

5

Instead of fighting systemd assumptions and legacy options which may or may not work, make your service and make your mount target depend on it.

My SMB shares are mounted from 192.168.1.2, change to what is correct in your case.

# /etc/systemd/system/wait-for-ping.service
[Unit]
Description=Blocks until it successfully pings 192.168.1.2
After=network-online.target

[Service]
ExecStartPre=/usr/bin/bash -c "while ! ping -c1 192.168.1.2; do sleep 1; done"
ExecStart=/usr/bin/bash -c "echo good to go"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Enable that service with:

sudo systemctl daemon-reload
sudo systemctl enable --now wait-for-ping.service

Then edit your fstab as follows to include this as final mount option:

x-systemd.after=wait-for-ping.service

Do another systemctl daemon-reload and you can verify that your mount target has the correct option set. My mount target is /mnt/media, that creates mnt-media.mount, so do:

systemctl cat mnt-media.mount

This should have an header like this:

# Automatically generated by systemd-fstab-generator

[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
After=wait-for-ping.service

# ... rest of file follows ...

Reboot your machine and you should find your mounts waiting until a ping succeeds.

1
  • Works very fine on Debian 12.
    – cweiske
    Commented Nov 15, 2023 at 20:36
2

Using only x-systemd.after=network-online.target as the accepted answer suggests didn't work for me, but the following combination of options worked:

x-systemd.automount,x-systemd.mount-timeout=30,_netdev,x-systemd.after=network-online.target
1
  • After fighting with this for a few weeks, your answer finally got things properly mounting on-boot in Debian 12.8. Commented Dec 22, 2024 at 20:18
1

A bit hacky, but all _netdev and x-systemd options didn't help, since WINS/DNS was stil not running.
I got going with a root crontab entry:

@reboot /usr/bin/mount -a

This is run late in the boot process.
So even if systemd fails in the first place to mount the CIFS mount defined in fstab, later a mount -a is run again and this time the mount succeeds.

1
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Mar 4, 2023 at 19:14
0

_netdev didn't help me because systemd sets that already for common/known network filesystems. Using x-systemd.after=network-online.target also didn't work for me, because systemd already implicitly waits for that. The problem for me was that network-online.target itself wasn't actually waiting until the network was online before continuing.

In my case it was trying to do the mount before DNS had started. I could see this because I enabled debugging in /etc/systemd/system.conf and rebooted, then used journalctl -u mnt-example.mount (for /mnt/example) to see why the mount failed. The error in there told me it couldn't resolve the hostname, so I knew it was a DNS problem.

This means I needed to tell network-online.target to wait until DNS was working before continuing with the network filesystem mounts.

I created a systemd service for this:

# /etc/systemd/system/[email protected] 
[Unit]
Description=Wait for DNS to be up
Before=network-online.target

# At once a second, give up after this many seconds.
StartLimitBurst=10

[Service]
Type=oneshot
ExecStart=host %i
Restart=on-failure
RestartSec=1

[Install]
WantedBy=network-online.target

This uses the host command to try to resolve the given DNS entry, retrying once a second for up to 10 seconds until it succeeds (or times out).

I tested it with systemctl start [email protected] to confirm it started successfully. Then I made it start at boot time with systemctl enable [email protected]. Obviously you'd change example.com to a hostname in your local network.

After enabling this service, the boot process paused for a couple of seconds until DNS was working before continuing, and all my network filesystems mounted successfully, without adding any extra mount options.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.