8

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
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN
6
  • fstab's fine, but fuse could be an issue. there are .mount units, too, though.
    – mikeserv
    Jul 15, 2015 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, 2015 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, 2015 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, 2015 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, 2015 at 14:01

3 Answers 3

9

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

5

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/22/2021 seems the line above is not correct (ever?). I have been using this below and it works. In this case to mount /opt to an alternative drive. I have not used auto as was suggested in comments

/mnt/data/opt   /opt    x-systemd.requires=/mnt/data,x-systemd.automount,none   bind    0   0
5
  • +-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, 2016 at 15:59
  • not working pastebin.com/raw/Ev6PaXAW
    – srghma
    Apr 28, 2018 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, 2018 at 15:37
  • your columns are wrong, change needed: filesystem column should be "auto" and "bind" should be in "options" column, i.e change "bind" to "auto bind," (not the comma)
    – glen
    Jan 19, 2021 at 16:53
  • @ glen ur right that is not what I am using now. But not exactly as you suggested. I have edited my post
    – DKebler
    Jan 22, 2021 at 19:52
2

You could also make unit files for these bind mounts:

[Mount]
What=/home/muru
Where=/where/ever/you/want/to
Type=none
Options=bind

[Install]
WantedBy=multi-user.target

The trick here is specifying "Type" as none, and "Options" as bind, similar to how you do it on cmd-line.

You can add wants/requires clauses, if the automatic ordering by dependency should fail.

You must log in to answer this question.

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