Open mtippmann opened 3 years ago
additional data:
~ » cat /proc/cmdline
initrd=\intel-ucode.img initrd=\initramfs-linux-zen.img zfs=tank/enc/ROOT/arch rw scsi_mod.use_blk_mq=1 zfs_force=1 apparmor=1 lsm=lockdown,yama,apparmor mds=off mitigations=off systemd.unified_cgroup_hierarchy=1 audit=1 threadirqs transparent_hugepage=madvise nmi_watchdog=0
~ » cat /etc/modprobe.d/zfs.conf
options zfs zfs_vdev_max_active=32
options zfs zfs_txg_timeout=5
options zfs zfs_vdev_scrub_min_active=1
options zfs zfs_vdev_scrub_max_active=2
# sync write
options zfs zfs_vdev_sync_write_min_active=4
options zfs zfs_vdev_sync_write_max_active=4
# sync reads (normal)
options zfs zfs_vdev_sync_read_min_active=4
options zfs zfs_vdev_sync_read_max_active=4
# async reads : prefetcher
options zfs zfs_vdev_async_read_min_active=1
options zfs zfs_vdev_async_read_max_active=4
# async write : bulk writes
options zfs zfs_vdev_async_write_min_active=1
options zfs zfs_vdev_async_write_max_active=4
# scheduler
options zfs zfs_vdev_scheduler=none
options zfs metaslab_lba_weighting_enabled=0
options zfs zfs_dirty_data_max_percent=15
options zfs zio_taskq_batch_pct=25
options zfs zfs_sync_taskq_batch_pct=25
options zfs zfs_prefetch_disable=1
options zfs zfs_arc_sys_free=1000000000
options zfs zfs_abd_scatter_enabled=0
more digging: zfs set mountpoint=somethingnew tank/enc/p
allows mounting the dataset - zfs unmount
/ zfs mount
work fine after that until rebooting, after reboot without changing the mountpoint mounting fails silent again.
This happens to me too, with kernel version 5.13.13-arch1-1 and zfs version zfs-2.1.0-1 and zfs-kmod-2.1.0-1. What's weird is that if I use the dkms version, it WILL mount the encrypted dataset on creation with canmount=noauto (with zfs mount pool/dataset,) but won't do so on reboot. However, the module version won't mount the dataset whatsoever.
EDIT: Also present in zfs-2.1.99-448_gb9ec4a15e zfs-kmod-2.1.99-1 (commit r7099) EDIT 2: it is also not possible to mount encrypted zvols (with key loaded). Apparently exporting the block device via iSCSI works though.
Are you by any chance using zfs root like me? I've just installed test system on a flash drive with ext4 and there is no issue. If I boot from the zfs root which is unencrypted btw, the issue is there. There could be a connection. Also I don't have nested datasets with different encpryption keys, just one encrypted dataset with children sharing the same key.
Similar issue, to the point where I believe this is the same issue: Mounting an encrypted dataset inside of an unencrypted dataset (on an unencrypted dataset) fails silently.
data/kescher
: normal dataset created with default options, no encryption.
data/kescher/test
: encrypted dataset with passphrase. key loaded before attempting mount, obviously.
Result: data/kescher/test
does not mount after creation nor after running zfs mount data/kescher/test
, but exits with exit code 0 and no output, as if the mount was successful.
Not a ZFS root, the pool is mounted at /mnt/data
.
Ah good it's not just me I was quite confused by this. I'm also running zfs on root. Versions: zfs-2.1.1-1, zfs-kmod-2.1.1-1 with kernel 5.14.18-1-MANJARO. I saw the same thing as @mtippmann where setting the mountpoint works until reboot. I was experimenting with this nice little rust tool shavee https://ashu.io/projects/shavee/ that lets you use a Yubikey to generate an encryption key when I noticed this behaviour.
On the machine I tried mounting encrypted datasets anywhere after rebooting, checking journalctl -xe
shows that right after trying to mount, the mount for those datasets is immediately stopped.
I'm having the same issue on kernel 5.15.25-1-lts. I don't have / on the encrypted dataset, it's supposed to get mounted in a directory in my home folder.
I ended up using this script as a workaround, after creating two empty folders zfs1/
and zfs2/
in my home directory and a file testfile.txt
in the root directory of the dataset:
#!/bin/bash
set -x
sudo zfs set canmount=on pool-raidz/bloatmode
sudo zfs set mountpoint=/home/bloatmode/zfs1 pool-raidz/bloatmode
sudo zfs mount -l pool-raidz/bloatmode
sleep 0.1
if [ -f "/home/bloatmode/zfs1/testfile.txt" ]
then
ln -snf /home/bloatmode/zfs1 /home/bloatmode/zfs
else
sudo zfs set mountpoint=/home/bloatmode/zfs2 pool-raidz/bloatmode
sudo zfs mount -l pool-raidz/bloatmode
ln -snf /home/bloatmode/zfs2 /home/bloatmode/zfs
fi
sudo zfs set canmount=noauto pool-raidz/bloatmode
Notice the sleep
call, it was necessary because the dataset would get mounted for a fraction of a second (I don't know exactly for how long) so the if statement would always return true.
The only reason I'm setting canmount
is because the computer is used by other people and with canmount=on
it would ask for a password on boot. canmount=off
would immediately unmount the dataset.
Update: after some days of using the above script I noticed that sometimes after a few hours the dataset is silently unmounted, but it can be remounted using the script. I also removed the last line from the script and used a systemd service instead, which sets canmount=off
before zed.service
is stopped. However even with canmount
set to on
while the computer is on, the dataset still gets unmounted silently every once in a while.
A cool new symptom appears! My encrypted datasets are mounted in the last mountpoint they used, rather than the current set one.
# zfs get mountpoint acentauri/vault
NAME PROPERTY VALUE SOURCE
acentauri/vault mountpoint /mnt/a -
# zfs inherit mountpoint acentauri/vault
# zfs get mountpoint acentauri/vault
NAME PROPERTY VALUE SOURCE
acentauri/vault mountpoint /mnt/acentauri/vault inherited from acentauri
# zfs mount acentauri/vault
# mount|grep vault
acentauri/vault on /mnt/a type zfs (rw,relatime,xattr,posixacl)
^^^^^^
Hi, since I had the same problem and was debugging this for nearly two days...
This seems to be a systemd problem when running root zfs, systemd creates a .mount and because of this it executes an immediate unmount of the newly mounted zfs dataset.
You should see the instant systemd unmounts in /var/log/daemon.log like this (or use journalctl):
Sep 22 11:19:20 s740deb systemd[1]: Unmounting /var/lib/docker/compose/srv...
Sep 22 11:19:20 s740deb systemd[1]: var-lib-docker-compose-srv.mount: Deactivated successfully.
So after the first mount you just do ¨systemctl daemon-reload" and it will work in future just as it should.
(I also added the datasets to fstab (with noauto), just to be sure.)
regards Sven
@SvenMb thank you! Can confirm that it works fine after masking the mount unit:
got this in the logs:
Sep 23 23:09:14 systemd[1]: Unmounting /home/mt/.p...
Sep 23 23:09:14 systemd[1]: home-mt-.p.mount: Deactivated successfully.
Sep 23 23:09:14 systemd[1]: Unmounted /home/mt/.p.
~ » systemctl mask home-mt-.p.mount
Created symlink /etc/systemd/system/home-mt-.p.mount → /dev/null.
~ » sudo zfs mount -l rpool/enc/p
~ » sudo zfs mount -l rpool/enc/p
cannot mount 'rpool/enc/p': filesystem already mounted
This also explains why mount()
returns 0 and works - now what the hell is going on with systemd here? why does changing the mountpoint works? Is this something that warrants a bug report for systemd?
Maybe systemd is not at fault here - could this be a bug in zfs-mount-generator?
After having this problem and seeing here that it was somewhat related to systemd the easiest workaround that I've found is doing
sudo systemctl start dpool-ARCHIVE-Personal.mount
instead of
sudo zfs mount -l dpool/ARCHIVE/Personal
Mind that for the systemd command the mountpoint has to be used instead of the dataset name, if different.
Actually, I've just noticed that @mtippmann's way is more convenient. I masked the unit:
sudo systemctl mask dpool-ARCHIVE-Personal.mount
and can use zfs mount
even after reboots.
I experienced this yesterday. This started happening after I enabled zfs-mount-generator
for one of my two pools. The one I enabled it for started experiencing this issue. The other one allowed me to mount things without any issue.
In sum: created file /etc/zfs/zfs-list.cache/POOL
(where POOL is my pool name). Toggled a property in my pool and enabled/started the ZFS Event Daemon.
An alternative solution to masking the generated .mount
file is simply to remove the /etc/zfs/zfs-list.cache/POOL
file and restarting zed. The .mount
units should be removed.
On Debian 12.2 I am currently facing exactly same issue according to description...
I have ZFS native encrypted dataset with canmount=noauto
, when I mount it manually by zfs mount it appears briefly and then disappears, rinse, repeat... Changing mountpoint helps for current session, but not after reboot... Methods of @luismcv mentioned seems to work.. But indeed something is fishy somewhere.
I am willing to help debug this some, if I get clear commands to run and report :)
ADD: Kernel: 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/Linux zfs-2.1.11-1 zfs-kmod-2.1.11-1
If the dataset is encrypted and zfs-mount-generator is enabled, the generated mount unit gets a strong dependency on the generated service that loads the encryption key:
BindsTo=zfs-load-key@data-enc0.service
BindsTo
has the effect that the depending unit (the mount) will be stopped, if the bound service is stopped. In other words: if the zfs-load-key@
service for the mount has not been started, filesystem will be immediately unmounted by systemd.
So it appears that the actual fix for this problem is to load encryption keys not by running zfs load-key
on the command line, but by running systemctl start zfs-load-key@<encryption root>
. After that, the service is active and the mount will succeed.
Does that make sense?
@tinuzz Thanks, was battling the same issue. It doesn't make a lot of sense from a user point of view.
zfs load-key
zfs mount ...
Would make a lot more sense :-)
Well, there's always man zfs-mount-generator
, that describes many ways to influence the generated units, or skip them altogether.
System information
Describe the problem you're observing
Trying to mount an encrypted dataset with a different passphrase below other encryped datasets. This used to work fine in the past but since some unknown date
zfs mount
fails silently -zfs mount -vvv
is also empty. It works after changing the mountpoint withzfs set mountpoint=/mnt/foo tank/enc/p
but after reboot mount fails.tank/enc
encryption roottank/enc/p
dataset that I'm not able to mount withcanmount=noauto
with a different passphraseDescribe how to reproduce the problem
I could only test with zfs git and kernel 5.13 / 5.10
create an encrypted dataset and a child dataset below that, change the passphrase for a child dataset and try to mount it after rebooting - doing a
zfs set mountpoint=somethingnew tank/enc/p
allows mounting the dataset -zfs unmount
/zfs mount
work fine after that until rebooting, after reboot without changing the mountpoint mounting fails silent again.Include any warning/errors/backtraces from the system logs
zfs list
zpool get all
zfs get all for the dataset that fails to mount (
zfs load-key
works fine):zdb:
strace (
mount()
syscall returns 0 but mount does not appear in/proc/mounts
)