I have a FreeNAS (11.1-U1) and a FreeBSD (11.1-RELEASE-p6) machine. On the FreeNAS I'd like to zfs receive
recursive snapshots as a non-root user with delegated privileges. This appears to work well for most of the child-datasets. But iocage's data
datasets, which can be mounted into the jail and administered from there, they fail:
root@freebsd:~> zfs send -RI "dozer@2018-02-21" "dozer@2018-03-08" | ssh -T -i /root/backup_key backupuser@freenas zfs receive -dvuF neo/backups/freebsd
receiving incremental stream of dozer@2018-03-03 into neo/backups/freebsd@2018-03-03
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of dozer@2018-03-07 into neo/backups/freebsd@2018-03-07
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of dozer@2018-03-08 into neo/backups/freebsd@2018-03-08
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of dozer/ROOT@2018-03-03 into neo/backups/freebsd/ROOT@2018-03-03
.
.
.
receiving incremental stream of dozer/iocage/jails/owncloud/root@2018-03-08 into neo/backups/freebsd/iocage/jails/owncloud/root@2018-03-08
received 578MB stream in 110 seconds (5.25MB/sec)
receiving incremental stream of dozer/iocage/jails/owncloud/root/data@2018-03-03 into neo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03
cannot receive incremental stream: permission denied
warning: cannot send 'dozer/iocage/jails/owncloud/root/data@2018-03-03': signal received
warning: cannot send 'dozer/iocage/jails/owncloud/root/data@2018-03-07': Broken pipe
warning: cannot send 'dozer/iocage/jails/owncloud/root/data@2018-03-08': Broken pipe
The permissions of that particular child are exactly the same as the one of the parent dataset:
root@freenas:~ # zfs allow neo/backups/freebsd/iocage/jails/owncloud/root/data
---- Permissions on neo/backups/freebsd -----------------------------
Local+Descendent permissions:
user backupuser atime,compression,create,dedup,exec,jailed,mount,mountpoint,quota,receive,rename,reservation,setuid,userprop
Running the zfs receive
on the FreeNAS as root works as expected.
What delegated privileges does my user need to receive the jailed datasets of iocage and, more generally, is there a way to make zfs receive
give out a more detailed error message which tells you what permission is missing?
Best Answer
When troubleshooting permission problems arising from
zfs
commands, analyze thezfs
operation in terms of its component steps.The sample command of
zfs receive -duvF
unpacks into several steps. Two of those flags do not relate to any special permissions:-d affects the naming of the new dataset (if any)
-v enables verbose output
The other two do.
-F means the filesystem will be rolled back to the initial snapshot of the incremental transfer before the receive starts
-u means the filesystem will not be mounted after the receive finishes
My hunch is that you're missing the rollback permission. The -F flag in your command implies that a
zfs rollback
will be performed, and yourzfs allow
does not listrollback
.In the general case, one can make deductive guesses about the permissions necessary for a given
zfs
command.The man page for
zfs
points out:and ...
The example at hand includes the
-u
flag, so the file system will not be mounted at the end of the receive operation. However, if-u
were absent, the filesystem would be mounted at the end of the receive process. Tellingly, thereceive
permission requires themount
permission.Because a
zfs mount
operation will auto-create any necessary mountpoints, it is possible for a user to havezfs
permission to mount the dataset, but not have filesystem permissions to create the mountpoint. In the case ofzfs mount
, the mount will fail. In azfs create
orrename
operation, the file system will be created or renamed, but it will remain unmounted if the user does not have sufficient filesystem permissions to create the mountpoint.Similarly, a
zfs rename
command could fail for lack of permissions at several points within the rename operation. Loosely expressed, the component steps might be:1) unmount the filesystem (
mount
permission)2) create a new filesystem (
create
permission)3) map the filesystem meta-data into the new name (
rename
permission)A fourth step is to re-mount the newly-named filesystem at its new, possibly changed mountpoint, which again uses the
mount
permission, and possibly filesystem permissions to create the new mountpoint.I have not tested such tricks, but it can be seen that
zfs
distinguishes betweencreate
andrename
permissions, and also betweenmount
andmountpoint
permissions. One imagines it might be possible to allow a user to create new filesystems, but once created, the user cannot rename them. For filesystems with inherited mountpoints, renaming a filesystem often also will rename the filesystem's mountpoint, as when renamingtank/usr/local
totank/usr/local.OLD
changes the mountpoint from/usr/local
to/usr/local.OLD
.The separation of
mount
orrename
frommountpoint
permissions means that a user could be allowed to rename a filesystem but not allowed to change its mountpoint. Or vice versa, to be able to change where a filesystem is mounted, but not be able to change the filesystem's name.The richness of its filesystem operations and delegation of those operations, coupled with the granularity of permissions, can make
zfs
somewhat challenging, but also very powerful.