NFS 설정으로 Ubuntu 18.04를 실행하는 서버가 있습니다. 해당 공유에 파일을 넣거나 조작하는 서비스와 네트워크를 통해 파일에 액세스하는 다른 클라이언트가 있습니다. NFS 서버가 모든 새 파일/폴더에 대한 기본 권한을 775로 설정하도록 하고 싶습니다.
새로 생성된 모든 파일과 폴더가 동일한 그룹을 상속하도록 폴더에 플래그를 설정했습니다 s. 따라서 해당 그룹의 모든 사용자는 해당 폴더에서 파일을 생성하고 수정할 수 있습니다. 하지만 NFS가 이를 수행하도록 강제할 수는 없습니다. 644의 새 파일과 2755의 폴더만 생성되었습니다.
여기 내/etc/exports/
/srv/nfs 192.168.11.0/24(ro,fsid=0,no_subtree_check,)
/srv/nfs/lpt-2tb 192.168.1.0/24(rw,sync,all_squash,no_subtree_check,insecure,anonuid=1002,anongid=1002)
1002는 사용자의 ID입니다 nfs.
나는 umask와 acl을 시도했지만 둘 다 소용이 없었습니다.
nfs 사용자를 위한 homedir을 생성하고 umask 002그 위치에 ~/.profile.
공유 폴더에 acl을 설정해 보았습니다.
/srv/nfs/lpt-2tb$ sudo setfacl -d --set u::rwx,g::rwx,o::r-x .
/srv/nfs/lpt-2tb$ sudo setfacl -R -m u::rwx,g::rwx .
/srv/nfs/lpt-2tb$ sudo getfacl .
# file: .
# owner: nfs
# group: nfs
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x
에 있는 nfs-server 구성을 수정 하고 섹션 아래에 /lib/systemd/system/nfs-server.service추가해 보았습니다 . 이것은 내가 직접 만든 다른 서비스에서는 작동했지만 NFS에서는 작동하지 않았습니다.UMask=002[Service]
NFS 서비스를 다시 시작하고 모든 수정 후에 재부팅해도 여전히 랩톱에서 공유로 파일을 복사하면 644 권한이 있습니다.
drwxr-sr-x+ 2 nfs nfs 4096 Apr 5 20:34 acl2
-rw-r--r-- 1 nfs nfs 434506 Mar 7 21:31 acl_test.png
---편집하다---
다음은 파일 및 폴더에 대한 ACL 출력입니다.
/srv/nfs/lpt-2tb$ sudo getfacl acl_test.png
# file: acl_test.png
# owner: nfs_share
# group: kodi
user::rw-
group::r--
other::r--
/srv/nfs/lpt-2tb$ sudo getfacl acl2
# file: acl2
# owner: nfs_share
# group: kodi
# flags: -s-
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x
---UPD---
내 서버가 nfs v2-3-4를 실행하고 있지만 클라이언트가 v3을 통해 연결되어 있고 이를 재정의할 수 없음을 확인했습니다. v4가 작동하게 되면 문제가 해결되는지 확인하려고 노력할 것입니다.
지금은 깨끗한 해결책을 찾는 것을 포기하고 주기적으로 권한을 확인하고 수정하는 크론 작업만 수행하겠습니다.
답변1
첫째, umask로 시도하는 작업이 작동하지 않습니다. umask는 프로세스별로 처리되며 중요한 프로세스는 파일을 생성하는 프로세스입니다. NFS 서버에 있는 nfs 사용자의 umask(이것이 의미하는 경우)는 NFS 클라이언트에서 nfs 사용자가 파일을 생성할 때 중요하지 않으며 NFS 서버 서비스 자체의 umask는 중요하지 않습니다. 아무것도 영향을 미치지 않습니다.
다음으로, NFS 공유에 파일을 복사할 때 잘못된 권한을 얻게 된다고 언급하셨습니다. "cp" 명령에서처럼 문자 그대로 복사를 의미한다고 가정하면 유효한 테스트가 아닙니다. cp 명령은 권한과 관련하여 다양한 특수 동작을 가지고 있습니다. 대부분의 프로그램과 달리 단순히 파일을 생성하고 기본 권한을 유지하는 것이 아니라 실제로 나중에 돌아가서 그에 대한 권한을 망쳐 놓습니다. 과거에 이에 대해 논의된 곳은 다음과 같습니다.
https://serverfault.com/questions/183800/why-does-cp-not-Respect-acls
저는 이런 종류의 테스트를 위한 파일을 생성하기 위해 "touch" 명령을 사용합니다. 시도해 보면 ACL 설정이 이미 잘 작동하고 있다는 것을 알게 될 것입니다. 이는 단지 cp 명령이 문제를 고려하지 않는 것일 뿐입니다.