Durante la risoluzione dei problemi di autorizzazione derivanti dai zfscomandi, analizzare l' zfsoperazione in termini di passaggi dei componenti.
Il comando di esempio di zfs receive -duvFdecomprime in più passaggi. Due di questi flag non si riferiscono ad autorizzazioni speciali:
-d influenza la denominazione del nuovo set di dati (se presente)
-v abilita un output dettagliato
Gli altri due lo fanno.
-F indica che il filesystem verrà ripristinato all'istantanea iniziale del trasferimento incrementale prima che inizi la ricezione
-u significa che il filesystem non verrà montato dopo il termine della ricezione
Il mio sospetto è che ti manchi l'autorizzazione di rollback. Il flag -F nel tuo comando implica che zfs rollbackverrà eseguito un, e il tuo zfs allownon viene elencato rollback.
Nel caso generale, si possono fare ipotesi deduttive sulle autorizzazioni necessarie per un dato zfscomando.
La pagina man per zfssottolinea:
I nomi delle autorizzazioni sono gli stessi dei nomi dei sottocomandi e delle proprietà ZFS.
e ...
Le autorizzazioni sono generalmente la capacità di utilizzare un sottocomando ZFS o modificare una proprietà ZFS. Sono disponibili le seguenti autorizzazioni:
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'esempio attuale include il -uflag, quindi il file system non verrà montato alla fine dell'operazione di ricezione. Tuttavia, se -ufosse assente, il filesystem verrebbe montato alla fine del processo di ricezione. Dire che l' receiveautorizzazione richiede l' mountautorizzazione.
Perché un zfs mounttestamento un'operazione di auto-crea alcun mountpoints necessario, è possibile per un utente di avere zfsil permesso di montare il set di dati, ma non avere le autorizzazioni del file system per creare il punto di montaggio. Nel caso di zfs mount, il montaggio fallirà. In un'operazione zfs createo rename, il file system verrà creato o rinominato, ma rimarrà smontato se l'utente non dispone di autorizzazioni sufficienti per creare il mountpoint.
Allo stesso modo, un zfs renamecomando potrebbe non riuscire per mancanza di autorizzazioni in diversi punti all'interno dell'operazione di ridenominazione. Liberamente espresso, i passaggi del componente potrebbero essere:
1) smontare il filesystem ( mountpermesso)
2) creare un nuovo filesystem ( createpermesso)
3) mappare i metadati del filesystem nel nuovo nome ( renamepermesso)
Un quarto passo consiste nel reinstallare il filesystem appena nominato nel suo nuovo mountpoint eventualmente modificato, che utilizza nuovamente l' mountautorizzazione e, eventualmente, le autorizzazioni del filesystem per creare il nuovo mountpoint.
Non ho testato questi trucchi, ma si può vedere che zfsdistingue tra createe renamepermessi, e anche tra mounte mountpointpermessi. Si immagina che potrebbe essere possibile consentire a un utente di creare nuovi filesystem, ma una volta creato, l'utente non può rinominarli. Per i filesystem con mountpoint ereditati, la ridenominazione di un filesystem spesso rinominerà anche il mountpoint del filesystem, come quando si rinomina tank/usr/localper tank/usr/local.OLDcambiare il mountpoint da /usr/locala /usr/local.OLD.
La separazione di mounto renamedalle mountpointautorizzazioni significa che un utente può essere autorizzato a rinominare un filesystem ma non può cambiare il suo mountpoint. O viceversa, per poter cambiare la posizione in cui è montato un filesystem, ma non per essere in grado di cambiare il nome del filesystem.
La ricchezza delle operazioni del suo filesystem e la delega di tali operazioni, insieme alla granularità delle autorizzazioni, possono rendere zfsun po 'impegnativo, ma anche molto potente.