私は FreeNAS (11.1-U1) と FreeBSD (11.1-RELEASE-p6) マシンを持っています。FreeNAS では、zfs receive委任された権限を持つ非ルート ユーザーとして再帰スナップショットを作成したいと考えています。これは、ほとんどの子データセットではうまく機能しているようです。しかし、datajail にマウントしてそこから管理できる iocage のデータセットでは失敗します。
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
その特定の子の権限は、親データセットの権限とまったく同じです。
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
zfs receiveFreeNAS 上で root として実行すると、期待どおりに動作します。
iocage の jail 化されたデータセットを受信するために、ユーザーにはどのような委任された権限が必要ですかzfs receive。また、より一般的には、不足している権限を示すより詳細なエラー メッセージを表示する方法はありますか。
答え1
zfsコマンドから発生する権限の問題をトラブルシューティングする場合は、zfs操作をその構成手順の観点から分析します。
のサンプル コマンドは、zfs receive -duvFいくつかのステップに分かれています。これらのフラグのうち 2 つは、特別な権限とは関係ありません。
-d は新しいデータセット（存在する場合）の名前に影響します
-v は詳細な出力を有効にします
他の2つはそうです。
-F は、受信開始前にファイルシステムが増分転送の初期スナップショットにロールバックされることを意味します
-u は、受信終了後にファイルシステムがマウントされないことを意味します
ロールバック権限がないのではないかと思います。コマンドの -F フラグは がzfs rollback実行されることを意味し、 は をzfs allowリストしませんrollback。
一般的なケースでは、特定のコマンドに必要な権限について演繹的に推測することができますzfs。
のマニュアルページにはzfs次のように記載されています:
権限名は、ZFS サブコマンドおよびプロパティ名と同じです。
そして ...
権限とは、通常、ZFS サブコマンドを使用したり、ZFS プロパティを変更したりする権限です。次の権限が利用可能です。
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
この例には-uフラグが含まれているため、受信操作の終了時にファイル システムはマウントされません。ただし、フラグ-uがない場合、ファイル システムは受信プロセスの終了時にマウントされます。つまり、receive権限には権限が必要ですmount。
zfs mount操作では必要なマウントポイントが自動的に作成されるため、zfsデータセットをマウントする権限はあっても、マウントポイントを作成するためのファイルシステム権限がないユーザーがいる可能性があります。 の場合zfs mount、マウントは失敗します。zfs createまたはrename操作では、ファイルシステムが作成または名前変更されますが、ユーザーにマウントポイントを作成するための十分なファイルシステム権限がない場合は、マウント解除されたままになります。
同様に、zfs rename名前変更操作のいくつかの時点で権限不足のためにコマンドが失敗する可能性があります。大まかに表現すると、コンポーネントの手順は次のようになります。
1) ファイルシステムをアンマウントする (mount権限 )
2) 新しいファイルシステムを作成する (create権限 )
3) ファイルシステムのメタデータを新しい名前にマップする (rename権限 )
4 番目のステップは、新しく名前が付けられたファイルシステムを、変更された可能性のある新しいマウントポイントに再マウントすることです。この場合も、権限mountと、場合によってはファイルシステムの権限を使用して、新しいマウントポイントが作成されます。
このようなトリックはテストしていませんが、が と の権限zfsを区別し、と の権限も区別していることがわかります。ユーザーが新しいファイルシステムを作成できるようにすることは可能かもしれませんが、いったん作成すると、ユーザーはその名前を変更できません。継承されたマウントポイントを持つファイルシステムの場合、ファイルシステムの名前を変更すると、多くの場合、ファイルシステムのマウントポイントの名前も変更されます。たとえば、に名前を変更すると、マウントポイントが から に変更されます。createrenamemountmountpointtank/usr/localtank/usr/local.OLD/usr/local/usr/local.OLD
mount権限renameの分離は、mountpointユーザーがファイルシステムの名前を変更することはできるが、そのマウントポイントを変更することはできないことを意味します。またはその逆で、ファイルシステムがマウントされている場所を変更することはできるが、ファイルシステムの名前を変更することはできないことになります。
豊富なファイルシステム操作とそれらの操作の委任、そして権限の細分化により、zfs多少困難ではありますが、非常に強力になります。
答え2
権限が欠落しているスナップショットがあるようです。
receiveに権限を設定してみてくださいneo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03。
ボリューム上では適切に設定されているように見えますが、スナップショットには設定されていません。