Ao solucionar problemas de permissão decorrentes de zfscomandos, analise a zfsoperação em termos de suas etapas de componente.
O comando de amostra zfs receive -duvFdescompacta em várias etapas. Dois desses sinalizadores não estão relacionados a nenhuma permissão especial:
-d afeta a nomeação do novo conjunto de dados (se houver)
-v ativa a saída detalhada
Os outros dois fazem.
-F significa que o sistema de arquivos será revertido para o instantâneo inicial da transferência incremental antes do início da recepção
-u significa que o sistema de arquivos não será montado após a conclusão do recebimento
Meu palpite é que você está perdendo a permissão de reversão. O sinalizador -F no seu comando implica que a zfs rollbackserá executada e a sua zfs allownão será listada rollback.
No caso geral, pode-se fazer deduções dedutivas sobre as permissões necessárias para um determinado zfscomando.
A página do manual zfsmostra:
Os nomes de permissão são iguais aos nomes de subcomando e propriedade do ZFS.
e ...
As permissões geralmente são a capacidade de usar um subcomando ZFS ou alterar uma propriedade ZFS. As seguintes permissões estão disponíveis:
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
O exemplo em questão inclui o -usinalizador, para que o sistema de arquivos não seja montado no final da operação de recebimento. No entanto, se -uestivesse ausente, o sistema de arquivos seria montado no final do processo de recebimento. É evidente que a receivepermissão requer a mountpermissão.
Como uma zfs mountoperação cria automaticamente todos os pontos de montagem necessários, é possível que um usuário tenha zfspermissão para montar o conjunto de dados, mas não tenha permissões do sistema de arquivos para criar o ponto de montagem. No caso de zfs mount, a montagem falhará. Em uma operação zfs createou rename, o sistema de arquivos será criado ou renomeado, mas permanecerá desmontado se o usuário não tiver permissões suficientes no sistema de arquivos para criar o ponto de montagem.
Da mesma forma, um zfs renamecomando pode falhar por falta de permissões em vários pontos da operação de renomeação. Expressas livremente, as etapas do componente podem ser:
1) desmonte o sistema de arquivos ( mountpermissão)
2) crie um novo sistema de arquivos ( createpermissão)
3) mapeie os metadados do sistema de arquivos para o novo nome ( renamepermissão)
Uma quarta etapa é remontar o sistema de arquivos recém-nomeado em seu novo ponto de montagem, possivelmente alterado, que novamente usa a mountpermissão e, possivelmente, permissões do sistema de arquivos para criar o novo ponto de montagem.
Eu não testei esses truques, mas ele pode ser visto que os zfsdistingue createe renamepermissões, e também entre mounte mountpointpermissões. Imagina-se que seja possível permitir que um usuário crie novos sistemas de arquivos, mas, uma vez criado, o usuário não poderá renomeá-los. Para sistemas de arquivos com pontos de montagem herdados, renomear um sistema de arquivos também renomeará o ponto de montagem do sistema de arquivos, como ao renomear tank/usr/localpara tank/usr/local.OLDalterar o ponto de montagem de /usr/localpara /usr/local.OLD.
A separação de mountou renamede mountpointpermissões significa que um usuário pode renomear um sistema de arquivos, mas não pode alterar seu ponto de montagem. Ou vice-versa, para poder alterar onde um sistema de arquivos está montado, mas não para alterar o nome do sistema de arquivos.
A riqueza de suas operações de sistema de arquivos e a delegação dessas operações, juntamente com a granularidade de permissões, podem tornar zfsum pouco desafiador, mas também muito poderoso.