systemd, trying to be smart, parallelizes mounting entries of /etc/fstab. Unfortunately, this randomly messes up bind mounts:

A look at my fstab, cleaned up a bit:

$ grep -Ev 'ntfs|swap|#' /etc/fstab
UUID=3cbb59fd-ff2c-47ed-955f-e4945b5c95b6   /           ext4        rw,relatime,data=ordered    0 1
UUID=2d7b3de8-782b-4981-9db6-a4b9a6d45cac   /home/muru/devel    ext4        rw,relatime,data=ordered    0 2
UUID=38d31418-ed63-49e8-b11b-df90da4833e2   /home/muru/var  btrfs       rw,relatime,space_cache 0 0
UUID=77307ad0-35e1-439b-8fe2-07a7bb5376b2   /mnt        ext4        rw,relatime,data=ordered    0 2
/home/muru /home/muru/devel/debian/jessie/home/muru none bind 0 0
/home/muru /home/muru/devel/debian/jessie-test/home/muru none bind 0 0
/home/muru/devel /home/muru/devel/debian/jessie/home/muru/devel none bind 0 0
/home/muru/devel /home/muru/devel/debian/jessie-test/home/muru/devel none bind 0 0

And my actual mounts:

$ mount | grep ^/dev/ | grep -Ev 'fuseblk|run'
/dev/sdb1 on / type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /mnt type ext4 (rw,relatime,data=ordered)
/dev/sda7 on /home/muru/devel type ext4 (rw,relatime,data=ordered)
/dev/sdb1 on /home/muru/devel/debian/jessie/home/muru type ext4 (rw,relatime,data=ordered)
/dev/sdb1 on /home/muru/devel/debian/jessie-test/home/muru type ext4 (rw,relatime,data=ordered)
/dev/sda7 on /home/muru/devel/debian/jessie-test/home/muru/devel type ext4 (rw,relatime,data=ordered)
/dev/sda7 on /home/muru/devel type ext4 (rw,relatime,data=ordered)
/dev/sda7 on /home/muru/devel/debian/jessie/home/muru/devel type ext4 (rw,relatime,data=ordered)
/dev/sda7 on /home/muru/devel/debian/jessie/home/muru/devel type ext4 (rw,relatime,data=ordered)
/dev/sda7 on /home/muru/devel/debian/jessie-test/home/muru/devel type ext4 (rw,relatime,data=ordered)
/dev/sda7 on /home/muru/devel type ext4 (rw,relatime,data=ordered)
/dev/sda7 on /home/muru/devel type ext4 (rw,relatime,data=ordered)
/dev/sdb8 on /home/muru/var type btrfs (rw,relatime,space_cache)
/dev/sdb8 on /home/muru/devel/debian/jessie/home/muru/var type btrfs (rw,relatime,space_cache)
/dev/sdb8 on /home/muru/devel/debian/jessie-test/home/muru/var type btrfs (rw,relatime,space_cache)

As you can see, it looks like the mounts have been done successfully. But, the effect:

$ ls -l /home/muru/devel/debian/jessie/home/
total 4.0K
drwxr-xr-x 2 root root 4.0K Jun 20 20:36 muru/
$ ls -l /home/muru/devel/debian/jessie/home/muru/
total 0

I think this is due to random ordering of the mounts. If that's the case, how do I ensure an order? Do I have to use something other than fstab? If that's not the case, what might have caused it?

I'm using Arch Linux.

$ systemctl --version
systemd 221
  • fstab's fine, but fuse could be an issue. there are .mount units, too, though. – mikeserv Jul 15 '15 at 21:03
  • You're bind mounting /home/muru to /home/muru/.../child/path? That's going to be problematic no matter who does the mounting. You need first to configure some path within as unbindable. The docs are here. – mikeserv Jul 16 '15 at 8:16
  • @mikeserv Why not? It worked fine enough on a non-systemd system or when I manually ran the mount -o bind commands. I'm not going to run any recursive commands on these paths. – muru Jul 16 '15 at 8:21
  • Ok, but the docs I linked to were the kernel docs on shared subtrees - not systemd docs. I don't know why systemd wouldn't do it correctly - it always handles my fstab binds correctly. I don't bind any fs loops, though. – mikeserv Jul 16 '15 at 8:24
  • I have a circular mount / -> /d/root and it seems to work (Debian 8). I can't work out how your result could follow from a mis-ordering. The mounts shown for non-existent directories are odd, it's almost as if they're still there but an empty filesystem was mounted on top later on. Can I suggest a) findmnt (it shows the source directory of binds as well) b) looking at inode numbers using stat, they should match for both the target and source directory. – sourcejedi Jul 16 '15 at 14:01

More than a year later with the version of systemd (229)now shipping with ubuntu 16.04 there is support in fstab for dependency mounting like this.

so it's as easy as doing this.

# /etc/fstab
/home/var /var bind x-systemd.requires=/home,x-systemd.automount,none 0 0

got the idea from this post https://copyninja.info/blog/systemd_automount_entry.html

  • +-1, but way too late to solve that particular problem. Maybe I'll use a similar setup in the future and test this out. – muru Nov 20 '16 at 15:59
  • not working pastebin.com/raw/Ev6PaXAW – srghma Apr 28 '18 at 7:46
  • This continues to work for me with new installs and later versions of systemd. maybe try getting a single bind mount to work first (also you may be editing the wrong file based on comments in file. Alternatively @srghama as to your particular application you may consider editing this file ~/.config/user-dirs.dirs instead. Not the same as bind mounts but may address your use case. – DKebler Apr 29 '18 at 15:37

Arnout's solution worked for me but there's a little mistake in it. Bind mounts in fstab must be like this (he swapped "bind" and "none"). Cf fstab manual.

# /etc/fstab
/home/var /var none x-systemd.requires=/home,x-systemd.automount,bind 0 0

Systemd mount reference is here : https://www.freedesktop.org/software/systemd/man/systemd.mount.html


To me systemd is a mess.

I've had to resort to just adding scripts to /etc/rc.local (or equivalent on your OS).

Just list all your mount points in the desired order.

This will circumvent systemd's "intelligence".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.