[SOLVED] Bind entry in fstab automounts even with noauto option

gieddy · 2024-03-07 02:04:57

Hello, I've decided to experiment with containers and specifically with systemd-nspawn recently. I have, however, decided to create a dedicated partition to host all of the containers.
I would like my partition to be mounted onto the the path /mnt/containers, and I would also like to bind mount /mnt/containers onto /var/lib/machines. Also, I would like for the drive not to be automounted on startup.
This is my fstab:

# /dev/sdb2
UUID=********   /          ext4            rw,relatime,stripe=256  0 1

# /dev/sdb1
UUID=********                               /boot      vfat            rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro    0 2

# /dev/sdb3
UUID=********                               /mnt/Data  exfat           users,rw,relatime,noauto        0 2

# containers
/mnt/containers                              /var/lib/machines  none    bind,noauto             0 0
UUID=********                                /mnt/containers    ext4    defaults,noauto         0 2

(UUIDs are all correct, I'm just not sure if posting them is safe (better safe than sorry))

However, when I boot my machine, I find that both /var/lib/machines and /mnt/containers have been automounted, as seen when running mount

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=8064684k,nr_inodes=2016171,mode=755,inode64)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda2 on / type ext4 (rw,relatime,stripe=256)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=332)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)
/dev/sda5 on /mnt/containers type ext4 (rw,relatime,stripe=256)
/dev/sda5 on /var/lib/machines type ext4 (rw,relatime,stripe=256)
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1615896k,nr_inodes=403974,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

and lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0   550M  0 part /boot
├─sda2   8:2    0   400G  0 part /
├─sda3   8:3    0    20G  0 part [SWAP]
├─sda4   8:4    0   300G  0 part 
└─sda5   8:5    0   100G  0 part /var/lib/machines
                                 /mnt/containers

Even weirder, if I run mount -a (which is what I guessed would the cause of this) after having manually umounted /dev/sda5 (2 times, one for each location), it doesn't automount anything.
And even MORE weird, if I than run sudo mount /var/lib/machines this is what happens:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0   550M  0 part /boot
├─sda2   8:2    0   400G  0 part /var/lib/machines
│                                /
├─sda3   8:3    0    20G  0 part [SWAP]
├─sda4   8:4    0   300G  0 part 
└─sda5   8:5    0   100G  0 part

(I don't really understand what's going on)

Last edited by gieddy (2024-03-07 20:40:56)

mpan · 2024-03-07 02:31:07

Hello. From `man fstab`:

noauto: do not mount when mount -a is given (e.g., at boot time)

`noauto` only affects `mount -a`, which is not being used during boot.⁽¹⁾ For systemd see systemd.mount. The implication is, that these units may still be pulled in as a dependency for another unit. So I would start by peeking into “/run/systemd/generator/” and seeing the contents of the mount units there.
____
⁽¹⁾ The example part may be misleading; it’s not saying `mount -a` certainly happens during boot. Instead, it’s an example of where it may happen.

Last edited by mpan (2024-03-07 02:31:41)

gieddy · 2024-03-07 03:14:12

First: thank you for clarifying this:

mpan wrote:

⁽¹⁾ The example part may be misleading; it’s not saying `mount -a` certainly happens during boot. Instead, it’s an example of where it may happen.

Second, I have inspected the files in /run/systemd/generator, and I would guess they are correct:
mnt-containers.mount

# Automatically generated by systemd-fstab-generator

[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target
Requires=systemd-fsck@dev-disk-by\x2duuid-*********.service
After=systemd-fsck@dev-disk-by\x2duuid-**********.service
After=blockdev@dev-disk-by\x2duuid-***********.target

[Mount]
What=/dev/disk/by-uuid/***********
Where=/mnt/containers
Type=ext4
Options=defaults,noauto

var-lib-machines.mount

# Automatically generated by systemd-fstab-generator

[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target

[Mount]
What=/mnt/containers
Where=/var/lib/machines
Type=none
Options=bind,noauto

However, it seems that var-lib-machines.mount is a dependency of remote-fs.target, as seen when running systemctl list-dependencies remote-fs.target:

remote-fs.target
● └─var-lib-machines.mount

And I don't understand why, since it would seem that

noauto, auto
With noauto, the mount unit will not be added as a dependency for local-fs.target or remote-fs.target. This means that it will not be mounted automatically during boot, unless it is pulled in by some other unit. The auto option has the opposite meaning and is the default.

Note that if x-systemd.automount (see above) is used, neither auto nor noauto have any effect. The matching automount unit will be added as a dependency to the appropriate target.

Added in version 215.

Last edited by gieddy (2024-03-07 11:45:44)

seth · 2024-03-07 08:28:21

/mnt/containers                              /var/lib/machines  none    bind,noauto             0 0
UUID=********                                /mnt/containers    ext4    defaults,noauto         0 2

First off, fix the order (it generally matters)
You certainly want to mount /mnt/containers first and then bind /var/lib/machines there, right?

Also please use [code][/code] tags, not "quote" tags. Edit your post in this regard (you'll see why)

gieddy · 2024-03-07 12:03:05

seth wrote:

/mnt/containers                              /var/lib/machines  none    bind,noauto             0 0
UUID=********                                /mnt/containers    ext4    defaults,noauto         0 2
First off, fix the order (it generally matters)
You certainly want to mount /mnt/containers first and then bind /var/lib/machines there, right?

I tried to do as you suggested, however it still appears that var-lib-machines.mount is a dependency of remote-fs.target.

seth wrote:

Also please use [code][/code] tags, not "quote" tags. Edit your post in this regard (you'll see why)

(p.s. thank you for pointing this out)

seth · 2024-03-07 15:22:23

I tried to do as you suggested, however it still appears that var-lib-machines.mount is a dependency of remote-fs.target.

1. did you reboot after altering the fstab?
2. I'd not worry so much about the remote condition* or even the bind mount, but rather: why is /mnt/containers mounted?

systemctl status mnt-containers.mount

And check your system journal for its mount.

* idk whether this works, but the local FS are mounted no_netdev, you could try whether explicitly adding that to the options (esp. of mnt/containers) alters the remote condition.

gieddy · 2024-03-07 17:41:09

I actualy found the culprit. If I had inspected the contents of /usr/lib/systemd/system/remote-fs.target.wants more carefully, I would have noticed that the symlink to var-lib-machines.mount didn't point to /run/systemd/generator. Rather it would seem that there exists a var-lib-machines.mount inside of /usr/lib/systemd/system, which is there for backwards compatibility reasons.
Now I only have to understand if removing the symlink inside of /usr/lib/systemd/system/remote-fs.target.wants is actually a good idea, or if there is a better way to override default .target.wants ...

Last edited by gieddy (2024-03-07 18:19:52)

seth · 2024-03-07 21:15:29

Wahhh, D'OHH.
You're not the only one not paying attention here.
It's the specific mount, not the bind.

pacman -Qo /usr/lib/systemd/system/remote-fs.target.wants/var-lib-machines.mount

https://www.freedesktop.org/software/sy … spawn.html

So the next question would be why you want to control the mount (noauto)
But the way to do this is to augment the system mount, https://wiki.archlinux.org/title/System … ided_units

Arch Linux

#1 2024-03-07 02:04:57

[SOLVED] Bind entry in fstab automounts even with noauto option

#2 2024-03-07 02:31:07

Re: [SOLVED] Bind entry in fstab automounts even with noauto option

#3 2024-03-07 03:14:12

Re: [SOLVED] Bind entry in fstab automounts even with noauto option

#4 2024-03-07 08:28:21

Re: [SOLVED] Bind entry in fstab automounts even with noauto option

#5 2024-03-07 12:03:05

Re: [SOLVED] Bind entry in fstab automounts even with noauto option

#6 2024-03-07 15:22:23

Re: [SOLVED] Bind entry in fstab automounts even with noauto option

#7 2024-03-07 17:41:09

Re: [SOLVED] Bind entry in fstab automounts even with noauto option

#8 2024-03-07 21:15:29

Re: [SOLVED] Bind entry in fstab automounts even with noauto option

Board footer