.zfs/snapshot automount does not work in linux namespace

[Mic92]

I use zfs as root filesystem in lxc. When trying to enter /.zfs/snapshot mount fails.
This is properly because the zfs kernel module shell out to mount, which is not in the same mount namespace as the lxc-container in question (/.zfs in the container is not the same as on the host)

$ lxc-attach -n parkendd
lxc> cd /.zfs/snapshot/zfs-auto-snap_hourly-*
lxc> exit
$ dmesg
Unable to automount data/containers/parkendd@zfs-auto-snap_hourly-2015-06-21-0502 at /.zfs/snapshot/zfs-auto-snap_hourly-2015-06-21-0502: 512

The container has the following capabilities:

chown dac_override dac_read_search fowner fsetid ipc_owner kill lease linux_immutable net_bind_service net_broadcast net_raw setgid setfcap setpcap setuid sys_admin sys_chroot sys_nice sys_ptrace sys_tty_config sys_resource sys_boot audit_write audit_control mknod

however this should make any difference because the mount is run on host (does it?).

$ uname -a
Linux eve 3.14.40-2-lts #1 SMP Fri May 1 13:58:47 CEST 2015 x86_64 GNU/Linux
$ modinfo zfs | head -n8
filename:       /lib/modules/3.14.40-2-lts/extra/zfs/zfs.ko
version:        0.6.4.1-1
license:        CDDL
author:         OpenZFS on Linux
description:    ZFS
srcversion:     8324F6AEA2A06B2B6F0A0F5
depends:        spl,znvpair,zunicode,zcommon,zavl
vermagic:       3.14.40-2-lts SMP mod_unload modversions

If you can give me a hint on how to solve this issue, I might create a patch on my own.

[behlendorf]

@Mic92 I think you may have answered your own question. Currently the .zfs/snapshot directories are triggered through the Linux auto-mounter which executes an upcall to do the actual mount. Unfortunately do the mount in the kernel isn't possible, and the upcall will run in the context of the host. If you could somehow find a way to do the mount in the context of the container I expect everything would work.

[micw]

Have a look to #616 which might be related to this issue. A few months ago I had a workaround with "mount --make-shared" but I cannot reproduce it anymore.

[eniac111]

Is there a something new about the problem?

[micw]

Hi. Do we have any progress with that issue? It also affects docker containers, so it's not possible to access snapshots from within the container :-(

[sdenovan]

This can be (inelegantly) hacked together if you're desperate for the functionality today:

1. Create a chrooted SFTP user (ie. SFTP instead of SSH for additional security) on the host that is restricted to the ZFS filesystem that backs the container. The UID/GID of the user should have access to the required files and directories. You may have to duplicate UIDs for this to be feasible. More info:

https://www.tecmint.com/restrict-sftp-user-home-directories-using-chroot/
Note: You can chroot to the user's home directory using "%h" which ssh understands in sshd_config. Google for more details.

2. The container must be allowed to fuse mount. Use fuse + sshfs (public key authentication) to mount the host's snapshot directory inside the container. Ideally, this should be done using AutoFS so that the connection isn't held open indefinitely and can be dynamically reconnected as needed.

Performance will vary but for a modern CPU at ~3Ghz with AES-NI, sshfs can sustain ~ 300MB/s (assuming your storage configuration can support that rate).

[Mic92]

One thing that could work, is to make .zfs a shared mountpoint, so that every mount in it is propagated to the container.

[DeHackEd]

That won't work in container situations where pivot_root is called to reorient the filesystem. The mount points are different in the perspectives of the host and container.

[Mic92]

Container could support this though. LXC for example has special support for zfs.

[evermind-micw]

@Mic92

Container could support this though. LXC for example has special support for zfs.

IMO that's the other end - containers can use zfs as their backend/overlay filesystem. The issue here is about using zfs features within the container (e.g. access a .zfs/snapshots directory)

[Mic92]

Yes. But I see no other way to implement this. zfs cannot rely on having a mount command in the container available. And if there is one, it should not execute it because it could be malicious. So cooperation with userspace is required.

[thoro]

I also would have needed this, but found a niceish workaround. I used the zfs snapshots for samba shadow copies, instead of accessing them directly, I redirected the shadow copies to a nfs share (which supports auto mounting of the snapshots - you have to enable nfs option crossmnt)

So maybe this would also be a solution for others with the problem