(The symlink is only so that SFTP clients don’t have to explicitly view hidden files, it’s not a prerequisite for reproducing the issue!)Ĭreate a few snapshots of the dataset: zfs snapshot zfs snapshot a test user (e.g. tank/backups/test01, mounted at /tank/backups/test01.Ĭreate some dummy files, and create a symlink at the top of the dataset, pointing to the hidden snapshots directory: ln -s.
OPENZFS SNAPSHOT HOW TO
Describe how to reproduce the problemĬreate a new dataset for hosting restricted client content, e.g. I first ran into this issue on Ubuntu 18.04, running distro-provided zfs/spl 0.7.5, although attempted this reproduction on Debian with the latest 0.8.0 release to see whether the #3778 discussion/fixes were landed after Ubuntu’s version. shows how to use a hybrid ZFS pool on an Unraid server using native Open ZFS for Linux. This appears to be extremely similar to #3778, and indicated various fixes landing in 0.6.x and 0.7.x, although perhaps it wasn’t fully resolved for all kinds of chroot? The error is clear, in that the mount operation is being called on the SFTP client’s view of the filesystem (where /tank/backups/test01 appears as /), even though it should be resolved outside of the chroot. It supports both snapshot redundancy and real-time redundancy. When attempting to browse auto-mounting ZFS dataset snapshots (.zfs/snapshot directory) over a chrooted SFTP (OpenSSH’s ChrootDirectory directive), snapshot access fails with the following error:īrowsing snapshots in this manner works as intended if ChrootDirectory is not set (not a workable solution, due to needing to restrict SFTP client access to the filesystem), and also works correctly on FreeBSD (11.2-RELEASE, 12.0-RELEASE), presumably because of differing methods of auto-mounting snapshot access. Can zfs tell the difference between snapshots taken recursively and snapshots taken one by one but using the same name Another question is about doing a recursive snapshot of pool which creates snapshots of its child datasets but also of itself ( pool1 and pool2 ).
0 kommentar(er)
