NFS経由でマウントされたUbuntuサーバーにフォルダがあるArch Linuxボックスがあります。すべての新しいファイルに権限が設定されるように、サーバー上のフォルダにアクセス制御リストを設定しました-rwx-r-x---
。
user1@ubuntu:~$ getfacl home/user2/shared/
# file: home/user2/shared/
# owner: user2
# group: remoteusers
user::rwx
group::r-x
other::---
default:user::rwx
default:user:user2:rwx
default:group::r-x
default:group:remoteusers:r-x
default:mask::rwx
default:other::---
ファイルを作成すると、権限が正しく設定されます。
userA@arch:~$ touch ubuntuNFS/test.txt
userA@arch:~$ ls -la ubuntuNFS
-rw-r----- 1 ########## ########## 0 Nov 13 2013 test.txt
ただし、ファイルをコピーすると、グループに権限は付与されません。
userA@arch:~$ cp Videos/video.mp4 ubuntuNFS/
userA@arch:~$ ls -la ubuntuNFS
-rw------- 1 ########## ########## 0 Nov 13 2013 video.mp4
-rw-r----- 1 ########## ########## 0 Nov 13 2013 test.txt
ACLのデフォルトが尊重されないのはなぜcp
ですか?
答え1
NFSでは、ACLがさまざまな方法でサポートされていることが時々あると思います。 NFSプロジェクトのウェブサイトでこの記事を参照してください。
それが問題ではなかった場合、私は非常に懐疑的でしたcp
。cp
ターゲットのインストールタイプに関係なく、ACLを完全にコピーしないコマンドのQ&Aが覚えているようです。
私はこれがU&L Q&Aのタイトルだと思います:setfacl を使用して、グループメンバーがディレクトリ内のすべてのファイルに書き込むことを許可する次のタイトルのSF Q&Aに移動します。cpがACLを尊重しないのはなぜですか?。
cp
皮肉なことに、私たちの@Gillesは、ACL伝播がサポートされていない理由を説明するSF Q&Aに対する回答を作成しました。私はこれが今でも本当だと信じています!
から抜粋@ギルズの答え
cp がターゲットファイルを生成すると、umask に設定されたビットを除いてソースファイルの権限がコピーされます。これは標準動作です(ステップ3.bを参照)。シングルUnix v3(POSIX 2001)仕様。
CPはなぜこのように設計されていますか?たとえば、元の権限が制限されている場合、ファイルのプライバシーを保護し、実行可能性を維持することがほぼ常に正しいことなど、この動作が望ましい状況がたくさんあるためです。残念ながら、GNU cpにもこの動作をオフにするオプションはありません。
ほとんどのレプリケーションツール(pax、rsyncなど)は同じように機能します。ソースをターゲットから切り離して(たとえば、 cat foo/baz を使用するなど)、デフォルトの権限でファイルを生成することができます。
はい
次のファイルを設定し、afile
ここにACLを追加しました。
$ touch afile
$ setfacl -m user:sam:rwx,group:users:rwx afile
現在、私たちは以下を持っています:
$ getfacl afile
# file: afile
# owner: root
# group: root
user::rw-
user:sam:rwx
group::r--
group:users:rwx
mask::rwx
other::r--
このファイルをNFSv3共有にコピーすると、次のようになります。
$ cp afile ~sam/
$ getfacl ~sam/afile
getfacl: Removing leading '/' from absolute path names
# file: home/sam/afile
# owner: root
# group: root
user::rw-
group::rwx
other::r--
ACLがありません。--preserve
スイッチを試してみてくださいcp
。
$ cp --preserve afile ~sam/
cp: preserving permissions for `/home/sam/afile': Operation not supported
cp: preserving ACL for `/home/sam/afile': Operation not supported
NFSでACLを有効にする
NFSマウントでACLを有効にしても効果がないようです。
mulder:/export/r1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,acl,rsize=16384,wsize=16384,addr=192.168.1.1)
$ cp --preserve afile ~sam/
cp: preserving permissions for `/home/sam/afile': Operation not supported
cp: preserving ACL for `/home/sam/afile': Operation not supported
同じハードドライブが正常に動作します。
--preserve
興味深いことに、このスイッチは同じEXT4インストールドライブにローカルにファイルをコピーするときに機能します。
$ cp --preserve afile afile2
$ getfacl afile2
# file: afile2
# owner: root
# group: root
user::rw-
user:sam:rwx
group::r--
group:users:rwx
mask::rwx
other::r--
これから進む道は?
私の研究と実験によると、ACLはNFSv4以下ではサポートされていないようです。cp
このコマンドは、基本ファイルシステムでサポートされている限りACLを保存できるようです。
次の記事を見つけました。プロジェクト:NFSバージョン4オープンソースリファレンスの実装、NFSv4でのACLの使用について説明します。したがって、ACLをNFSv4共有にコピーすることは可能ですが、NFSv2やNFSv3を使用することは不可能です。
引用する
答え2
1つの可能な解決策は強制的にマスク保存する前方十字靭帯。
同じグループと所有者の権限を共有する必要があるユーザーに権限を付与して設定します。SGID共有フォルダでグループ共有を許可するには、フォルダに対する正しい権限を適用してください。
つまり、フォルダをグループごとに共有していないのと同じ構成を実行します。前方十字靭帯実施中です。