2

I have two servers on my home network:

  • A Linux server. (Currently running Debian with systemd, but I don't think there is anything Debian-specific here.)
  • A NAS server. (Network Attached Storage.)

After a power outage, both servers get turned on at the same time. However, the Linux server boots up quickly, quicker than the NAS server. The Linux server has access to the network, tries to mount the CIFS share, and fails because the NAS server is not ready yet.

How to make the Linux server auto-mount the CIFS mount even if the NAS server takes longer to start up? (How long? Let's assume a couple of minutes.)

Current configuration

The Linux server has this kind of line at /etc/fstab (anonymized):

//192.168.XX.XX/Foobar  /mnt/Foobar  cifs  credentials=/etc/fstab-cifs-credentials,rw,uid=1000,gid=1000,nobrl  0  0

It is also running systemd, and sudo systemctl show mnt-Foobar.mount shows the network dependency was automatically configured:

…
Wants=network-online.target
After=system.slice network.target systemd-journald.socket network-online.target remote-fs-pre.target -.mount
…

The error message displayed by journalctl or by sudo systemctl status mnt-Foobar.mount:

mount[544]: mount error(113): could not connect to 192.168.XX.XXUnable to find suitable address.

Mounting works well if triggered manually, or if I reboot the Linux server after the NAS server is up.

What's needed

I need a solution that would retry mounting a few times, with some delay between each try, before completely giving up.

Or a solution that would continuously retry mounting.

Or a solution that would consider the mount successful even if the server is not ready yet, on the belief that the server will be eventually ready. (And any access should block for a few minutes if the server isn't ready.)

Or a solution to introduce a fixed arbitrary delay before mounting the network filesystems.

Bonus: service dependencies

I have a few docker services that use files stored on the NAS. Such docker services have a volume mapping from /mnt/Foobar into the docker container. Thus, it is imperative that the docker services only start up AFTER all the CIFS mounts are ready.

Setting up such service dependency is a topic for another question. However, the solution to THIS question should play nicely with the docker startup dependency.

Workaround

My current workaround is to manually ssh into the Linux server and either reboot it or manually mount the shares. (And manually restart the docker services.) Definitely not ideal, requires too much baby-sitting of the server.

7
  • Simplest thing I can come up with is running mount -a every minute through cron
    – Panki
    Dec 17, 2023 at 23:34
  • 1
    Mounting an external "unreliable" filesystem unconditionally via fstab makes booting the system both slow and unreliable. Maybe autofs ("automount") is a better solution: It will try to mount the filesystem when it's attempted to be used for the first time (and it will unmount it if unused for some time).
    – U. Windl
    Dec 17, 2023 at 23:37
  • Just write a systemd unit for that. Dec 18, 2023 at 9:39
  • @U.Windl Well, the filesystem will be used shortly, when the docker containers start up. Thus, I don't see any benefit on the autofs. Dec 18, 2023 at 10:22
  • @ArtemS.Tashkinov, so, can you provide an answer to this question here, helping me to write a systemd unit for that? What would that unit look like? What purpose would it have? How to write it? Any further documentation I should know? If a new systemd unit is the solution, there is plenty to write about it. Dec 18, 2023 at 10:23

3 Answers 3

1

Simple add 'x-systemd.automount' to your fstab, like this :

//192.168.XX.XX/Foobar  /mnt/Foobar  cifs  credentials=/etc/fstab-cifs-credentials,rw,uid=1000,gid=1000,nobrl,x-systemd.automount  0  0

Systemd will handle everything for you.

1
  • I've added the results from my experiments. In summary, your solution seems to work fine, as indeed those mount points threw an error when accessing before mounting, and then became available automatically later. Jan 31 at 12:35
0

Totally untested:

$ cat /usr/local/libexec/cifs-mounter.sh
#! /bin/bash
SRV=192.168.0.111 # FQDN or IP address
while ! nc -z $SRV 445; do
    sleep 10
done

mount -t cifs //$SRV/share /mnt/point
$ cat /etc/systemd/system/multi-user.target.wants/cifs-mounter.service
[Unit]
Description=CIFS mounter
After=network.target

[Service]
ExecStart=/usr/local/libexec/cifs-mounter.sh
KillMode=process
Restart=on-failure
RestartSec=30s

[Install]
WantedBy=multi-user.target
0

TL;DR: Add x-systemd.automount to the mount options, as per Zardoz89's answer.

Now I have a different problem of (re)starting docker containers that failed due to being started too early. But that's a different question.


The official documentation is available at man systemd.mount. This article from SUSE Support is also helpful.

_netdev

There is an option _netdev, but it's not needed, because:

Normally the file system type is used to determine if a mount is a "network mount", i.e. if it should only be started after the network is available. Using this option overrides this detection and specifies that the mount requires network.

Indeed, I compared the output of systemctl show mnt-Foobar.mount for two mount units (one with and one without that option), and they were very similar. Specifically, After, RequiredBy, RequiresMountsFor, Requires and Wants were equivalent (but somehow in different order; but the order doesn't matter anyway).

x-systemd.automount

Following Zardoz89's answer, I tried adding x-systemd.automount to my mount points.

After rebooting, I can check it was detected by looking at systemctl list-automounts or systemctl list-units '*mount*'.

Trying to access anything inside those directories returns an error:

$ tree
.
└── Foobar  [error opening dir]

$ ls -R
.:
Foobar
ls: cannot open directory './Foobar': No such device

Thankfully, as soon as the shared folder became available on the server, those directories started working again.

Docker failures

The docker containers that were depending on volumes from those shared folders still failed to start and were still down even after those volumes became available. Maybe I can just add a few healthchecks to work around that issue. Or try using But that's a different question anyway.

Service dependencies

If you have systemd units for each of your services, you can declare mount point dependencies directly in the /etc/fstab file, by adding one (or more) of these options:

  • x-systemd.after=
  • x-systemd.before=
  • x-systemd.required-by=
  • x-systemd.wanted-by=

The meaning of each one is explained in man systemd.unit.

x-systemd.device-timeout and x-systemd.mount-timeout (didn't work for me)

Let's assume you don't want to use x-systemd.automount. Well, you can still declare and increase the timeout for mounting those devices, using:

  • x-systemd.device-timeout=
  • x-systemd.mount-timeout=

The time can be specified in s or min (and also h or ms, for whatever reason).

However, when I tried using those, they didn't work. Even though I had a 15-minute timeout, after rebooting those mount points still showed as failed. So, either these don't work, or they don't work for me because I don't understand them well enough.

This can be combined with systemd dependencies to make sure your services are only started at the right moment.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .