이 문제는 기본적으로 이 시점에서 나를 미치게 만듭니다. 이 구성에서 제대로 작동하는 Ubuntu 16.04 NFS 서버가 있습니다.
/etc/fstab:
UUID=b6bd34a3-f5af-4463-a515-be0b0b583f98 /data2 xfs rw,relatime 0 0
/data2 /srv/nfs/cryodata none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
그리고
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
이것은 지금까지 다음 클라이언트 측 /etc/fstab 항목을 사용하여 이 구성을 사용하는 하나의 nfs 클라이언트에서 몇 달 동안 잘 작동했습니다.
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
그러나 이는 매우 큰 스토리지 서버이기 때문에 여러 실험실을 수용해야 한다고 결정되었습니다. 그래서 /data2 파티션에 흩어져 있던 모든 항목을 /data2/cryodata 하위 디렉터리로 옮겼고, 서버의 /etc/fstab과 /etc/exports를 다음과 같이 업데이트했습니다.
/etc/fstab:
...
/data2/cryodata /srv/nfs/cryodata none defaults,bind 0 0
/data2/xray /srv/nfs/xray none defaults,bind 0 0
/data2/EM /srv/nfs/EM none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
그리고
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/EM 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/xray 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
이것은 단순히 작동하지 않습니다! 동일한 클라이언트 /etc/fstab 항목을 사용하여 클라이언트에 새 마운트를 마운트하려고 하면 다음과 같습니다.
{nfs client} /etc/fstab:
...
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
.
# mount -v /cryodata
mount.nfs4: timeout set for Sat Feb 24 09:24:38 2018
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=128.83.41.171,clientaddr=129.116.159.31'
...
/usr/local은 문제 없이 계속 마운트됩니다. 이 작업을 처음 시도했을 때 exportfs -var변경하기 전에 파일 시스템 내보내기/내보내기를 잊어버렸습니다. 그러나 그 이후로 여러 번 서버를 재부팅하면서 모든 항목을 내보내고 마운트 해제하는 데 주의하면서 앞뒤로 전환했습니다. 전체 파티션의 바인드 마운트의 원래 마운트는 항상 작동하며 하위 디렉토리의 바인드 마운트는 매번 오래된 nfs 핸들 메시지와 함께 실패합니다. 이러한 파티션을 마운트한 적이 없는 다른 nfs 클라이언트를 활성화하려고 시도했지만 정확히 동일한 오류 메시지가 나타납니다. 이 경우에는 확실히 서버 측 문제입니다. 마운트 시도 등 사이에 지워졌는지 확인하기 위해 /var/lib/nfs/etab을 확인했습니다.
나는 nfs 서버 루트 디렉토리에 바인드 마운트하는 기술이 이러한 모든 종류의 문제를 해결했다고 생각했지만 분명히 그렇지 않습니까? 이상한 점은 /usr/local이 다른 파티션의 하위 디렉터리이고 항상 잘 마운트된다는 것입니다. ext3 md raid 1에 있지만 이것이 중요하다고는 상상할 수 없습니다.
나는 이것에 몇 시간을 보냈고 아무 소용이 없는 해결책을 찾기 위해 Google을 거의 망가뜨렸습니다.
답변1
바인드 마운트 파일 시스템만 내보내고 있다는 점에 유의하세요. 이 섹션은수출매뉴얼 페이지는 관련이 있습니다:
fsid=num|root|uuid
NFS는 내보내는 각 파일 시스템을 식별할 수 있어야 합니다. 일반적으로 파일 시스템에 대한 UUID(파일 시스템에 그런 것이 있는 경우) 또는 파일 시스템을 보유하는 장치의 장치 번호(파일 시스템이 장치에 저장된 경우)를 사용합니다.
내 잘못된 가정은 바인드 마운트 파일 시스템에 NFS가 자동으로 사용할 수 있는 일종의 UUID가 있다는 것입니다. 그리고 이러한 바인드 마운트 내보내기가 fsid 없이도 잘 작동했다는 사실로 인해 가정이 강화되었습니다.
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
그러나 이로 인해 일관되지 않은 동작이 발생합니다. /opt 마운트 바인드를 추가했습니다.
/etc/fstab:
/data1/opt /srv/nfs/opt none defaults,bind 0 0
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,no_subtree_check)
일관되지 않은 행동을 초래했습니다. 즉, 내보내기 IP를 변경하고 한 시스템에 마운트할 수 있지만 다른 시스템에서는 권한이 거부될 수 있습니다. 해결책은 fsid를 추가하는 것이었습니다.
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,fsid=20,no_subtree_check)
따라서 해결책은 바인드 마운트 파일 시스템을 내보내려면 항상 fsid를 추가하는 것입니다.