ONTAP NFS access denied — ONTAP에서 NFS 볼륨을 만들고 리눅스 클라이언트에서 마운트했는데 이 한 줄만 돌아옵니다.
mount.nfs: access denied by server while mounting 192.168.126.20:/nfs_vol1네트워크는 멀쩡하고, NFS 서비스도 켜져 있고, showmount 도 응답합니다. 그런데 마운트만 안 됩니다.
결론부터 말하면 export policy에 룰이 없어서입니다. 그런데 이게 간단하지 않습니다. 볼륨에만 정책을 걸고 SVM 루트 볼륨을 빠뜨리면 똑같은 증상이 납니다. 이 글은 그 두 가지를 구분해서 짚습니다.
이 글의 실습 환경
이 글은 ONTAP Simulator 9.17.1 기반 가상 랩에서 직접 명령을 실행하고 그 출력을 근거로 작성했습니다. VMware Workstation Pro 25H2 위에 2노드 클러스터를 구성한 환경입니다.
실제 장비(FAS/AFF)와는 다음과 같은 차이가 있을 수 있습니다.
- 시뮬레이터가 지원하지 않는 기능이 있습니다. 예를 들어 HA(스토리지 페일오버)는 2노드 클러스터를 구성해도 동작하지 않습니다.
- 성능 수치는 의미가 없습니다. 가상 디스크 기반이라 실제 처리량·지연시간과 무관합니다.
- 하드웨어에 의존하는 동작(디스크 물리 장애, 셸프 인식, FC 포트 등)은 재현되지 않거나 다르게 동작합니다.
- ONTAP 버전에 따라 명령과 출력이 달라집니다. 이 글은 9.17.1 기준입니다.
운영 환경에 적용하기 전에는 반드시 해당 버전의 NetApp 공식 문서와 자사 환경에서 검증하시기 바랍니다.
1. 환경
| 구성 | 값 |
|---|---|
| 스토리지 | ONTAP Simulator 9.17.1, 2노드 |
| SVM | NFS_SVM |
| 데이터 LIF | 192.168.126.20 |
| 볼륨 | nfs_vol1, junction /nfs_vol1, security-style unix |
| 클라이언트 | Ubuntu Server 24.04.4 LTS |
sudo apt install -y nfs-common2. 증상 — 하나씩 지워도 답이 안 나온다
네트워크는 정상
$ ping -c 2 192.168.126.20
2 packets transmitted, 2 received, 0% packet lossNFS 서비스도 정상
cluster1::> vserver nfs status
The NFS server is running on Vserver "NFS_SVM".
cluster1::> vserver nfs show
Vserver: NFS_SVM
General Access: true
v3: enabled
v4.0: disabled
4.1: disabled
TCP: enabled이 랩은 v3만 켜져 있습니다. 이 글의 마운트는 전부 NFSv3 기준입니다.
showmount 도 응답한다 — 오히려 이게 함정이다
$ showmount -e 192.168.126.20
Export list for 192.168.126.20:
/ (everyone)/ (everyone). 모두에게 열려 있다고 보고합니다. 여기까지 보면 안 될 이유가 없습니다.
그런데 마운트는 거부된다
$ sudo mount -t nfs 192.168.126.20:/nfs_vol1 /mnt/ontap-nfs
mount.nfs: access denied by server while mounting 192.168.126.20:/nfs_vol1에러는 이 한 줄이 전부입니다. 왜 거부했는지는 말해주지 않습니다.
3. 어디를 봐야 하는가
3-1. 볼륨에 어떤 export policy가 붙어 있는지부터 본다
cluster1::> volume show -vserver NFS_SVM -fields volume,policy,junction-path,security-style
vserver volume policy security-style junction-path
------- ------------ ------- -------------- -------------
NFS_SVM NFS_SVM_root default unix /
NFS_SVM nfs_vol1 default unix /nfs_vol1여기서 두 가지를 봐야 합니다.
- 데이터 볼륨(
nfs_vol1)에 붙은 정책 - SVM 루트 볼륨(
NFS_SVM_root, junction/)에 붙은 정책 ← 자주 빠뜨리는 곳
정책이 할당은 되어 있습니다. 그래서 더 헷갈립니다.
3-2. 그 정책에 룰이 있는지 본다
cluster1::> vserver export-policy rule show
This table is currently empty.여기가 원인입니다. 정책은 붙어 있는데 그 안에 룰이 하나도 없습니다.
정책이 할당된 것과 그 정책에 룰이 있는 것은 다릅니다. 룰이 없는 정책은 “아무도 허용하지 않음”으로 동작합니다.
3-3. 왜 showmount 는 정상으로 보였나
showmount -e 는 네임스페이스에 무엇이 export되어 있는지를 보여줍니다. 개별 클라이언트가 실제로 접근 가능한지를 검사한 결과가 아닙니다.
| 명령 | 확인하는 것 |
|---|---|
showmount -e | export 대상이 네임스페이스에 존재하는가 |
| 실제 mount | 이 클라이언트에게 접근 권한이 있는가 |
showmount 가 응답한다고 마운트가 되는 게 아닙니다.
4. 가장 많이 빠뜨리는 곳 — SVM 루트 볼륨
여기가 이 글에서 제일 중요한 부분입니다.
볼륨마다 export policy를 따로 만들어 쓰는 경우가 많습니다. 그런데 데이터 볼륨에만 정책을 걸고 SVM 루트(/)를 그대로 두면 접근이 안 됩니다.
클라이언트가 /nfs_vol1 에 닿으려면 먼저 / 를 지나가야 하기 때문입니다. 루트가 막혀 있으면 그 아래는 볼 수도 없습니다.
NetApp 공식 문서가 이걸 첫 문장으로 못박고 있습니다.
The default export policy of the SVM root volume must include a rule to allow all clients open access through NFS. Without such a rule, all NFS clients are denied access to the SVM and its volumes.
You should verify that access is open to all NFS clients in the default export policy, and later restrict access to individual volumes by creating custom export policies for individual volumes or qtrees.
— Open NFS client access on the ONTAP SVM, NetApp 공식 문서
그래서 방법은 둘 중 하나입니다
| 방식 | 내용 |
|---|---|
| A. 문서 권장 | 루트의 default 정책은 열어두고, 제한은 개별 볼륨의 커스텀 정책으로 건다 |
| B. 단순하게 | 처음부터 default 정책만 쓰고 거기에 권한을 준다 |
볼륨마다 정책을 만들어 쓰는 구성에서 사고가 납니다. 실사용 볼륨 정책만 신경 쓰고 루트를 잊으면, 정책은 완벽해 보이는데 클라이언트는 아무것도 못 봅니다.
고객 환경에 따라 다르지만 기본적으로는 A 방법을 대체로 씁니다. 제재 없이 단순하게 사용할 경우에는 B처럼 씁니다.
5. 해결
루트 볼륨의 default 정책부터 엽니다.
cluster1::> vserver export-policy rule create -vserver NFS_SVM -policyname default -clientmatch 0.0.0.0/0 -rorule any -rwrule any -superuser any -protocol any데이터 볼륨용 정책에도 룰을 만듭니다.
cluster1::> vserver export-policy rule create -vserver NFS_SVM -policyname nfs_vol1 -clientmatch 0.0.0.0/0 -rorule any -rwrule any -superuser any -protocol any확인:
cluster1::> vserver export-policy rule show
Policy Rule Access Client RO
Vserver Name Index Protocol Match Rule
------------ --------------- ------ -------- --------------------- ---------
NFS_SVM default 1 any 0.0.0.0/0 any
NFS_SVM nfs_vol1 1 any 0.0.0.0/0 any운영 환경에서는 0.0.0.0/0 을 쓰지 않습니다
랩이라 전부 열었습니다. 운영에서는 접근하는 사용자나 서버 IP를 개별로 지정하는 것이 원칙입니다. 다만 실제 설정 방식은 사이트 성격에 따라 매번 다릅니다 — 대역 단위로 묶는 곳도 있고 호스트 단위로 관리하는 곳도 있습니다.
-superuser 도 마찬가지입니다. any 로 열면 클라이언트의 root가 스토리지에서도 root로 동작합니다. 필요한 호스트에만 주고 나머지는 기본값으로 두는 편이 안전합니다.
6. 마운트 성공
$ sudo mount -t nfs 192.168.126.20:/nfs_vol1 /mnt/ontap-nfs
$ df -h /mnt/ontap-nfs
Filesystem Size Used Avail Use% Mounted on
192.168.126.20:/nfs_vol1 973M 320K 973M 1% /mnt/ontap-nfs
$ sudo touch /mnt/ontap-nfs/write-test.txt
$ ls -la /mnt/ontap-nfs/
drwxrwxrwx 2 root root 4096 .snapshot
-rw-r--r-- 1 root root 0 write-test.txt읽기·쓰기 모두 정상입니다.
7. 마운트 출력에서 두 가지를 더 읽는다
$ mount | grep ontap-nfs
192.168.126.20:/nfs_vol1 on /mnt/ontap-nfs type nfs
(rw,relatime,vers=3,rsize=65536,wsize=65536,hard,proto=tcp,sec=sys,...)7-1. vers=3 — 어느 버전으로 붙었는지 확인하는 습관
협상 결과가 마운트 옵션에 그대로 찍힙니다. 이 랩은 v3만 켜뒀으므로 NFSv3 입니다.
꺼진 버전을 강제 지정하면 이렇게 거부됩니다.
$ sudo mount -t nfs -o vers=4.1 192.168.126.20:/nfs_vol1 /mnt/ontap-nfs
mount.nfs: Protocol not supported에러 메시지가 다릅니다. 이 차이가 진단에 쓸모 있습니다.
| 에러 | 볼 곳 |
|---|---|
access denied by server | export policy 룰 |
Protocol not supported | vserver nfs show -fields v3,v4.0,v4.1 |
7-2. v4를 쓸 때 주의할 것 — 사용자가 nobody 로 보인다
v3든 v4든 어느 쪽을 써도 무방합니다. 다만 v4에는 v3에 없는 함정이 있습니다.
클라이언트에서 마운트했을 때 파일 소유자가 전부 nobody 로 보이는 현상입니다. 권한이 잘못된 게 아니라 사용자 ID 매핑이 안 맞아서 그렇습니다.
By default, ONTAP uses the NIS domain for NFSv4 user ID mapping, if one is set. If an NIS domain is not set, the DNS domain is used. You might need to set the user ID domain if, for example, you have multiple user ID domains. The domain name must match the domain configuration on the domain controller. It is not required for NFSv3.
— Specify the ONTAP user ID domain for NFSv4, NetApp 공식 문서
즉 서버와 스토리지의 도메인이 일치해야 정상적인 사용자로 보입니다.
cluster1::> vserver nfs modify -vserver NFS_SVM -v4-id-domain <도메인>이 설정은 NFSv3에는 필요 없습니다. v4로 넘어갈 때만 신경 쓰면 됩니다.
8. 재부팅 후에도 유지하려면 — /etc/fstab
192.168.126.20:/nfs_vol1 /mnt/ontap-nfs nfs defaults,_netdev 0 0$ sudo systemctl daemon-reload
$ sudo mount -a
$ df -h /mnt/ontap-nfs
192.168.126.20:/nfs_vol1 973M 384K 973M 1% /mnt/ontap-nfs_netdev 는 넣는 편이 좋습니다. 네트워크가 올라온 뒤에 마운트하도록 순서를 보장합니다. 없으면 부팅 시 네트워크보다 먼저 마운트를 시도해 실패할 수 있습니다.
nofail 은 취향이 갈립니다
fstab(5) man page의 정의는 “do not report errors for this device if it does not exist” 입니다. 실재하는 옵션이고, 스토리지에 못 붙어도 부팅은 되게 합니다.
| 선택 | 논리 |
|---|---|
| 넣는다 | 스토리지 장애 시에도 서버는 뜬다. 콘솔 없는 환경에서 안전 |
| 안 넣는다 | 마운트 실패가 부팅 단계에서 드러난다. 조용히 넘어가면 더 위험하다는 관점 |
실무에서는 마운트 옵션만 넣고 nofail 은 쓰지 않는 경우가 많습니다. 정답이 있는 항목은 아닙니다. 콘솔로 붙기 어려운 환경이라면 넣는 쪽이, 마운트 실패를 부팅 단계에서 바로 잡고 싶다면 빼는 쪽이 맞습니다.
9. 정리 — 어디를 봐야 하는가
| 확인 항목 | 명령 |
|---|---|
| 네트워크 | ping |
| NFS 서비스 | vserver nfs status |
| 프로토콜 버전 | vserver nfs show -fields v3,v4.0,v4.1 |
| 볼륨별 export policy | volume show -fields volume,policy,junction-path |
| 정책에 룰이 있는가 | vserver export-policy rule show |
SVM 루트(/) 정책 | 위 두 명령으로 함께 확인 |
기억할 두 문장
- 정책이 볼륨에 할당된 것과 그 정책에 룰이 있는 것은 다릅니다.
- 데이터 볼륨만 열고 SVM 루트를 빠뜨리면 아무것도 안 보입니다.
에러 메시지가 원인을 잘못 가리키는 사례를 하나 더 보시려면 ONTAP CIFS 도메인 조인이 “LDAP Error”로 실패할 때 — 진짜 원인은 역방향 DNS를 읽어보십시오. 그쪽은 LDAP 이라고 적혀 있지만 실제 원인은 DNS였습니다.
