Linux NFS 클라이언트·서버

NFS 연결 오류와 파일 권한 오류를 구분합니다

경로, NFS 버전, exports, UID 매핑을 나누어 확인합니다.

어느 단계에서 실패했는지부터 봅니다

findmnt -t nfs,nfs4
nfsstat -m
ip route get 192.0.2.10

192.0.2.10은 문서용 예시 주소이며 실제 서버로 바꿉니다. 경로가 선택되었다고 서버까지 통신이 성공했다는 뜻은 아닙니다. No route to host는 라우팅뿐 아니라 네트워크의 거부 응답에서도 보일 수 있습니다. NFS 버전만 바꿔 모든 연결 문제를 해결할 수는 없습니다.

NFS 문제를 확인하는 단계
  1. IP 연결주소·경로·방화벽·서버 응답을 확인합니다.
  2. NFS 서비스와 공유지원 버전과 export 경로·허용 클라이언트를 확인합니다.
  3. 파일 접근서버 파일 권한과 UID/GID 매핑을 확인합니다.

번호는 진단 순서입니다. 마운트 성공은 모든 파일의 읽기·쓰기를 보장하지 않습니다.

root_squash의 뜻이 뒤바뀌면 안 됩니다

옵션의미
root_squash클라이언트의 UID/GID 0을 익명 계정으로 매핑합니다. 기본 동작입니다.
no_root_squash위 매핑을 하지 않습니다. 클라이언트 root의 서버 접근 영향을 크게 바꿉니다.
all_squash모든 사용자 ID를 익명 계정으로 매핑합니다.
no_subtree_check하위 디렉터리가 공유에서 제외된다는 뜻이 아닙니다. 파일핸들의 하위 트리 검사를 끕니다.

AUTH_SYS를 사용하는 구성에서는 서버가 받는 숫자 UID/GID와 서버 파일 소유권을 비교해야 합니다. 이름이 같아도 숫자가 다를 수 있습니다. Kerberos 보안 방식은 인증과 ID 매핑의 조건이 다르므로 별도로 확인합니다.

허용할 클라이언트와 권한을 명시합니다

/srv/shared 192.0.2.20(rw,sync,root_squash,no_subtree_check)

exports 문법 설명용 예입니다. 한 클라이언트 주소만 지정했고, 호스트 이름과 괄호 사이에는 공백을 넣지 않습니다. 실제 사용 전에 서버의 파일 권한과 목적에 맞는 보안 방식을 정합니다. *와 no_root_squash를 편의상 넣으면 접근 범위와 root 매핑을 함께 넓히게 됩니다.

sync/async는 서버가 완료를 응답하는 저장 조건에 영향을 줍니다. nolock은 모든 버전의 오류를 해결하는 일반 옵션이 아닙니다. NFSv3에서 쓰는 부가 RPC 서비스와 NFSv4 경로·서비스 구성이 다르므로 실제 사용 버전의 로그를 확인합니다.

확인한 문서

Linux NFS 클라이언트·서버