Al solucionar problemas de permisos que surgen de los zfscomandos, analice la zfsoperación en términos de los pasos de sus componentes.
El comando de muestra zfs receive -duvFdesempaqueta en varios pasos. Dos de esas banderas no se relacionan con ningún permiso especial:
-d afecta la nomenclatura del nuevo conjunto de datos (si corresponde)
-v habilita la salida detallada
Los otros dos lo hacen.
-F significa que el sistema de archivos se revertirá a la instantánea inicial de la transferencia incremental antes de que comience la recepción
-u significa que el sistema de archivos no se montará después de que finalice la recepción
Mi presentimiento es que te estás perdiendo el permiso de reversión. El indicador -F en su comando implica que zfs rollbackse realizará un, y su zfs allowno aparece en la lista rollback.
En el caso general, uno puede hacer conjeturas deductivas sobre los permisos necesarios para un zfscomando dado .
La página del manual para zfsseñala:
Los nombres de los permisos son los mismos que los del subcomando ZFS y los nombres de propiedad.
y ...
Los permisos son generalmente la capacidad de usar un subcomando ZFS o cambiar una propiedad ZFS. Los siguientes permisos están disponibles:
NAME TYPE NOTES
allow subcommand Must also have the permission
that is being allowed
clone subcommand Must also have the 'create'
ability and 'mount' ability in
the origin file system
create subcommand Must also have the 'mount'
ability
destroy subcommand Must also have the 'mount'
ability
diff subcommand Allows lookup of paths within a
dataset given an object number,
and the ability to create
snapshots necessary to 'zfs diff'
hold subcommand Allows adding a user hold to a
snapshot
mount subcommand Allows mount/umount of ZFS
datasets
promote subcommand Must also have the 'mount' and
'promote' ability in the origin
file system
receive subcommand Must also have the 'mount' and
'create' ability
release subcommand Allows releasing a user hold
which might destroy the snapshot
rename subcommand Must also have the 'mount' and
'create' ability in the new
parent
rollback subcommand Must also have the 'mount'
ability
send subcommand
share subcommand Allows sharing file systems over
the NFS protocol
snapshot subcommand Must also have the 'mount'
ability
groupquota other Allows accessing any
groupquota@... property
groupused other Allows reading any groupused@...
property
userprop other Allows changing any user property
userquota other Allows accessing any
userquota@... property
userused other Allows reading any userused@...
property
aclinherit property
aclmode property
atime property
canmount property
casesensitivity property
checksum property
compression property
copies property
dedup property
devices property
exec property
filesystem_limit property
logbias property
jailed property
mlslabel property
mountpoint property
nbmand property
normalization property
primarycache property
quota property
readonly property
recordsize property
refquota property
refreservation property
reservation property
secondarycache property
setuid property
sharenfs property
sharesmb property
snapdir property
snapshot_limit property
sync property
utf8only property
version property
volblocksize property
volsize property
vscan property
xattr property
El ejemplo en cuestión incluye la -ubandera, por lo que el sistema de archivos no se montará al final de la operación de recepción. Sin embargo, si -uno existiera, el sistema de archivos se montaría al final del proceso de recepción. De manera reveladora, el receivepermiso requiere el mountpermiso.
Debido a que una zfs mountoperación creará automáticamente los puntos de montaje necesarios, es posible que un usuario tenga zfspermiso para montar el conjunto de datos, pero no tenga permisos del sistema de archivos para crear el punto de montaje. En el caso de zfs mount, el montaje fallará. En una zfs createo renamefuncionamiento, se creará el sistema de archivos o cambiado de nombre, pero permanecerá sin montar si el usuario no tiene suficientes permisos de acceso a archivos para crear el punto de montaje.
Del mismo modo, un zfs renamecomando podría fallar por falta de permisos en varios puntos dentro de la operación de cambio de nombre. Expresado libremente, los pasos componentes pueden ser:
1) desmontar el sistema de archivos ( mountpermiso)
2) crear un nuevo sistema de archivos ( createpermiso)
3) asignar los metadatos del sistema de archivos al nuevo nombre ( renamepermiso)
Un cuarto paso es volver a montar el sistema de archivos recién nombrado en su nuevo punto de montaje posiblemente modificado, que nuevamente usa el mountpermiso y posiblemente los permisos del sistema de archivos para crear el nuevo punto de montaje.
No he probado tales trucos, pero se puede ver que zfsdistingue entre createy renamepermisos, y también entre mounty mountpointpermisos. Uno imagina que podría ser posible permitir que un usuario cree nuevos sistemas de archivos, pero una vez creado, el usuario no puede cambiarles el nombre. Para los sistemas de archivos con puntos de montaje heredados, el cambio de nombre de un sistema de archivos a menudo también cambiará el nombre del punto de montaje del sistema de archivos, como cuando se cambia el nombre tank/usr/localpara tank/usr/local.OLDcambiar el punto de montaje de /usr/locala /usr/local.OLD.
La separación de mounto renamede los mountpointpermisos significa que se podría permitir a un usuario cambiar el nombre de un sistema de archivos pero no se le permitiría cambiar su punto de montaje. O viceversa, para poder cambiar dónde está montado un sistema de archivos, pero no poder cambiar el nombre del sistema de archivos.
La riqueza de sus operaciones del sistema de archivos y la delegación de esas operaciones, junto con la granularidad de los permisos, pueden ser zfsun tanto desafiantes, pero también muy poderosos.
Parece que tiene una instantánea donde falta el permiso.
Intenta establecer el
receivepermisoneo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03.Parece que está configurado correctamente en el volumen, pero falta en la instantánea.
fuente