Lors du dépannage des problèmes d'autorisation résultant des zfscommandes, analysez l' zfsopération en termes d'étapes de ses composants.
L'exemple de commande de zfs receive -duvFdécompresser en plusieurs étapes. Deux de ces indicateurs ne concernent aucune autorisation spéciale:
-d affecte la dénomination du nouvel ensemble de données (le cas échéant)
-v active la sortie détaillée
Les deux autres le font.
-F signifie que le système de fichiers sera restauré à l'instantané initial du transfert incrémentiel avant le début de la réception
-u signifie que le système de fichiers ne sera pas monté une fois la réception terminée
Mon intuition est que vous manquez l'autorisation de restauration. L'indicateur -F dans votre commande implique qu'un zfs rollbacksera exécuté et votre zfs allowne sera pas répertorié rollback.
Dans le cas général, on peut faire des suppositions déductives sur les autorisations nécessaires pour une zfscommande donnée .
La page de manuel pour zfssouligne:
Les noms d'autorisation sont les mêmes que les noms de sous-commande et de propriété ZFS.
et ...
Les autorisations sont généralement la possibilité d'utiliser une sous-commande ZFS ou de modifier une propriété ZFS. Les autorisations suivantes sont 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
L'exemple présenté comprend l' -uindicateur, de sorte que le système de fichiers ne sera pas monté à la fin de l'opération de réception. Cependant, s'il -uétait absent, le système de fichiers serait monté à la fin du processus de réception. Fait révélateur, l' receiveautorisation nécessite l' mountautorisation.
Puisqu'une zfs mountopération créera automatiquement tous les points de montage nécessaires, il est possible pour un utilisateur d'avoir l' zfsautorisation de monter l'ensemble de données, mais pas les autorisations de système de fichiers pour créer le point de montage. Dans le cas de zfs mount, le montage échouera. Dans une opération zfs createor rename, le système de fichiers sera créé ou renommé, mais il restera démonté si l'utilisateur ne dispose pas des autorisations de système de fichiers suffisantes pour créer le point de montage.
De même, une zfs renamecommande peut échouer par manque d'autorisations à plusieurs moments de l'opération de renommage. Librement exprimé, les étapes des composants peuvent être:
1) démonter le système de fichiers ( mountautorisation)
2) créer un nouveau système de fichiers ( createautorisation)
3) mapper les métadonnées du système de fichiers dans le nouveau nom ( renameautorisation)
Une quatrième étape consiste à remonter le système de fichiers nouvellement nommé à son nouveau point de montage, éventuellement modifié, qui utilise à nouveau l' mountautorisation et éventuellement les autorisations du système de fichiers pour créer le nouveau point de montage.
Je ne l' ai pas testé ces trucs, mais il peut être vu que zfsétablit une distinction entre createet renameautorisations, et aussi entre mountet mountpointautorisations. On imagine qu'il pourrait être possible d'autoriser un utilisateur à créer de nouveaux systèmes de fichiers, mais une fois créé, l'utilisateur ne peut pas les renommer. Pour les systèmes de fichiers avec des points de montage hérités, renommer souvent un système de fichiers renommera également le point de montage du système de fichiers, comme lors d'un changement tank/usr/localde nom pour tank/usr/local.OLDchanger le point de montage de /usr/localà /usr/local.OLD.
La séparation des autorisations mountou renamedes mountpointautorisations signifie qu'un utilisateur peut être autorisé à renommer un système de fichiers mais pas autorisé à modifier son point de montage. Ou vice versa, pour pouvoir changer l'endroit où un système de fichiers est monté, mais ne pas pouvoir changer le nom du système de fichiers.
La richesse de ses opérations sur le système de fichiers et la délégation de ces opérations, associées à la granularité des autorisations, peuvent rendre zfsquelque peu difficile, mais aussi très puissant.