[홈랩] NAS NFS 공유 설정 오류 해결: 연결 끊김 및 권한 문제 디버깅

목차

• 1. NAS NFS 공유, 쉽게 말해 뭐가 문제를 만드는 걸까요?
• 2. 먼저 증상부터 분류해보면 원인이 빨리 보입니다
• 3. 실전 1단계: NAS NFS 공유 서버 설정부터 점검합니다
• 서버에서 꼭 같이 보는 로그
• 4. 실전 2단계: 클라이언트에서 NFS 마운트와 버전 확인
• 재부팅 후 자동 마운트가 깨질 때
• 5. 가장 많이 막히는 권한 문제, UID/GID부터 봐야 합니다
• 6. ⚠️ 연결 끊김이 반복될 때 제가 체크하는 순서
• 7. NAS NFS 공유 정상 동작 검증: 읽기·쓰기·자동 마운트
• 8. 자주 묻는 질문 정리
• Q1. SMB는 되는데 NFS만 안 되는 이유가 뭘까요?
• Q2. NFSv3와 NFSv4 중 무엇이 더 좋을까요?
• Q3. 권한이 꼬이면 777로 풀면 되나요?
• Q4. Proxmox나 Docker에서 NAS NFS 공유를 붙일 때 팁이 있나요?
• 9. 마무리: 결국 NAS NFS 공유 문제는 순서가 답입니다

[홈랩] NAS NFS 공유 설정 오류 해결: 연결 끊김 및 권한 문제

홈랩이나 사무실에서 NAS NFS 공유를 붙여 쓰다 보면, 어느 날 갑자기 마운트는 되는데 파일이 안 보이거나, 잘 되다가 연결이 툭 끊기고, 쓰기는커녕 읽기 권한도 이상하게 꼬이는 순간이 옵니다. 저도 처음엔 이게 스토리지 문제인지, 네트워크 문제인지, 아니면 리눅스 권한 문제인지 감이 안 오더라고요. 실제로 써보니까 NFS(Network File System, 네트워크 파일 시스템)는 단순히 공유 하나 켠다고 끝나는 게 아니라, export 설정, UID/GID 매핑, 클라이언트 마운트 옵션, 방화벽이 다 맞아야 조용히 돌아갑니다.

이번 글에서는 제가 홈랩에서 겪었던 연결 끊김, 권한 문제, 네트워크 공유 오류 해결 과정을 기준으로 정리해보겠습니다. 특정 NAS 벤더 화면만 다루기보다, Synology, QNAP, TrueNAS, 일반 Linux NFS 서버까지 공통으로 적용할 수 있는 디버깅 흐름 위주로 설명드릴게요. 혹시 지금 마운트는 되는데 접근이 안 되거나, 재부팅 후 다시 깨지는 증상을 겪고 계시면 순서대로 따라가 보시면 됩니다.

NAS NFS 공유 환경에서 서버, 클라이언트, 네트워크, 권한 매핑 흐름을 한눈에 보여주는 개요 이미지입니다.

1. NAS NFS 공유, 쉽게 말해 뭐가 문제를 만드는 걸까요?

쉽게 말해 NFS는 서버가 디렉터리를 내보내고(export), 클라이언트가 그 경로를 원격 디스크처럼 마운트(mount)해서 쓰는 구조입니다. SMB(Samba, 윈도우 파일 공유)보다 가볍고 리눅스끼리 붙일 때 편한 편이거든요. 그래서 Docker(도커) 볼륨, Proxmox(프록스목스) 백업 저장소, 미디어 서버 라이브러리, VM 이미지 저장소로 많이 씁니다.

근데 여기서 중요한 게 하나 있어요. NFS는 로그인 창이 뜨는 방식이 아니라, 누가 접속했는지 IP와 UID/GID로 판단하는 경우가 많습니다. 그래서 서버 쪽에서는 잘 열어뒀다고 생각했는데, 클라이언트에서 접근하면 Permission denied가 뜨는 경우가 흔합니다. 저도 처음엔 폴더 권한을 777로 풀어보는 삽질부터 했었는데, 사실 핵심은 그게 아니라 누가 어떤 권한으로 보이느냐였어요.

대표적으로 문제를 만드는 지점은 아래 네 가지입니다.

• export 설정 오류: 허용 IP, 읽기/쓰기 옵션, squash 설정이 잘못된 경우
• 권한 매핑 문제: 서버와 클라이언트의 UID/GID가 달라 파일 소유자가 꼬이는 경우
• 네트워크 문제: 방화벽, VLAN, MTU, DNS 또는 IP 변경으로 접속이 불안정한 경우
• 마운트 옵션 문제: 부팅 시점, 타임아웃, NFS 버전 불일치로 연결 끊김이 생기는 경우

2. 먼저 증상부터 분류해보면 원인이 빨리 보입니다

제가 직접 해보니 제일 빨랐던 방법은 증상을 먼저 나누는 거였습니다. NFS는 에러 메시지가 친절하지 않은 편이라, 증상 기반으로 접근해야 시간 낭비가 줄어들더라고요.

증상	가능성 높은 원인	우선 확인할 것
마운트 자체가 안 됨	export 미허용, 포트 차단, 버전 불일치	showmount, 방화벽, NFSv3/NFSv4
마운트는 되는데 폴더가 비어 보임	경로 오타, 잘못된 export 경로	서버 실제 경로, NAS 공유 경로
읽기는 되는데 쓰기가 안 됨	권한, root_squash, UID/GID 불일치	ls -ln, id, export 옵션
잘 되다가 끊김	네트워크 불안정, 타임아웃, 부팅 순서	dmesg, syslog, fstab 옵션
재부팅 후 다시 깨짐	자동 마운트 타이밍 문제	_netdev, automount, network-online

이 표만 머리에 넣고 가도 디버깅 속도가 꽤 빨라집니다. 특히 연결 끊김과 권한 문제는 겉보기엔 비슷해 보여도 완전히 다른 계층의 문제인 경우가 많습니다.

3. 실전 1단계: NAS NFS 공유 서버 설정부터 점검합니다

서버 쪽 설정이 틀어져 있으면 클라이언트에서 뭘 해도 답이 안 나옵니다. 그래서 저는 항상 서버부터 확인합니다. NAS 제품을 쓰더라도 내부적으로는 NFS export 개념이 같기 때문에, 화면 이름만 다를 뿐 확인 포인트는 거의 비슷합니다.

1. 공유 폴더가 실제로 존재하는지 확인합니다.
2. NFS 서비스가 활성화되어 있는지 봅니다.
3. 허용할 클라이언트 IP 또는 대역이 정확한지 봅니다.
4. 읽기/쓰기(Read/Write) 권한이 맞는지 확인합니다.
5. root_squash 또는 익명 사용자 매핑 설정을 확인합니다.

Linux NFS 서버 기준으로 보면 설정 파일은 보통 /etc/exports 입니다. 예시는 아래처럼 잡을 수 있습니다.

sudo mkdir -p /srv/nas-share
sudo chown -R 1000:1000 /srv/nas-share
sudo chmod 775 /srv/nas-share

cat /etc/exports
/srv/nas-share 192.168.0.0/24(rw,sync,no_subtree_check)

설정을 반영할 때는 다음처럼 확인하면 됩니다.

sudo exportfs -rav
sudo exportfs -v
showmount -e localhost

여기서 showmount -e localhost 결과에 내가 내보낸 경로가 안 보이면, 클라이언트에서 아무리 마운트를 시도해도 안 됩니다. 별거 아닌데 이 단계에서 많이 막히거든요. 저도 경로를 /volume1/data로 착각해서 한참 헤맨 적이 있습니다.

NFS export 경로, 읽기/쓰기 권한, 허용 클라이언트 IP 대역을 시각적으로 보여주는 설정 예시 이미지입니다.

서버에서 꼭 같이 보는 로그

에러가 애매하면 로그가 거의 유일한 단서입니다. 배포판마다 조금 다르지만 보통 아래 정도는 확인해볼 만합니다.

sudo journalctl -u nfs-server --since "-30 min"
sudo dmesg | tail -n 50
sudo ss -tulpn | grep nfs

NAS 장비에서는 시스템 로그 또는 파일 서비스 로그 메뉴에서 비슷한 정보를 볼 수 있습니다. 메시지가 짧아도 괜찮습니다. 핵심은 접속이 거부됐는지, 경로를 못 찾는지, 권한이 안 맞는지를 구분하는 겁니다.

4. 실전 2단계: 클라이언트에서 NFS 마운트와 버전 확인

서버 설정이 정상이라면 이제 클라이언트 차례입니다. 여기서 많이 나오는 문제가 NFS 버전과 마운트 옵션입니다. 어떤 환경은 NFSv4가 기본인데, 어떤 NAS는 NFSv3에서 더 안정적으로 붙는 경우도 있거든요. 무조건 최신이 답은 아니더라고요.

우선 수동 마운트로 테스트합니다. 자동 마운트부터 건드리면 실패 원인이 묻혀버립니다.

sudo mkdir -p /mnt/nas-test
sudo mount -t nfs -o vers=4 192.168.0.10:/srv/nas-share /mnt/nas-test

mount | grep nas-test
ls -al /mnt/nas-test

NFSv4가 안 되면 NFSv3도 시도해봅니다.

sudo umount /mnt/nas-test
sudo mount -t nfs -o vers=3 192.168.0.10:/srv/nas-share /mnt/nas-test

여기서 마운트는 되는데 읽기/쓰기가 불안정하면, 다음처럼 네트워크와 커널 메시지를 같이 봅니다.

dmesg | tail -n 100
ping -c 4 192.168.0.10
ip addr
ip route

제가 실제로 겪었던 케이스 중 하나는, 서버 IP는 고정이라고 생각했는데 DHCP 예약이 꼬여서 주소가 바뀐 경우였습니다. 마운트 설정은 살아 있는데 대상이 달라져 있으니 이상한 증상이 계속 나왔죠. 그래서 가능하면 NAS NFS 공유 환경에서는 고정 IP 또는 DHCP reservation을 권장합니다.

재부팅 후 자동 마운트가 깨질 때

이건 홈랩에서 정말 자주 봅니다. 네트워크가 올라오기 전에 마운트를 시도해서 실패하는 경우인데요, /etc/fstab에 최소한 아래 옵션은 많이 씁니다.

192.168.0.10:/srv/nas-share /mnt/nas-test nfs defaults,_netdev,noatime,x-systemd.automount,x-systemd.requires=network-online.target 0 0

_netdev는 네트워크 장치가 준비된 뒤에 다루라는 힌트이고, x-systemd.automount는 실제 접근 시점에 마운트해줘서 부팅 실패를 줄이는 데 꽤 유용합니다. 드디어 됐다 싶었던 순간이 이 옵션 추가한 뒤였어요.

5. 가장 많이 막히는 권한 문제, UID/GID부터 봐야 합니다

사실 NFS 디버깅의 절반은 권한입니다. 특히 컨테이너나 여러 리눅스 장비가 동시에 붙는 환경에서는 더 그렇습니다. 파일이 서버에서는 1000:1000 소유인데, 클라이언트에서는 해당 UID/GID를 다른 사용자로 해석하면 권한이 꼬여 보일 수 있거든요.

먼저 서버와 클라이언트 양쪽에서 숫자 기준으로 확인합니다.

id
ls -ln /srv/nas-share
ls -ln /mnt/nas-test

여기서 중요한 건 이름이 아니라 숫자 UID/GID입니다. 이름은 같아도 숫자가 다르면 다른 사용자입니다. 저도 처음엔 계정명이 같아서 괜찮은 줄 알았는데, 숫자가 달라서 쓰기 권한이 계속 실패하더라고요.

대표적인 권한 이슈는 이렇습니다.

• root_squash: 클라이언트의 root를 서버에서 낮은 권한 사용자로 매핑합니다.
• all_squash: 모든 사용자를 익명 사용자로 매핑합니다.
• anonuid/anongid: 익명 매핑 대상을 특정 UID/GID로 고정합니다.

예를 들어, 특정 서비스 계정으로 일관되게 쓰고 싶으면 이런 식의 설정을 고려할 수 있습니다.

/srv/nas-share 192.168.0.0/24(rw,sync,no_subtree_check,anonuid=1000,anongid=1000)

다만 이건 환경에 따라 의도와 다르게 권한이 단순화될 수 있으니, 무조건 넣기보다 왜 쓰는지 알고 적용하셔야 합니다. 보안이 중요한 환경에서는 더 신중해야 하고요.

Docker(도커)나 Kubernetes(쿠버네티스)에서 붙일 때도 비슷합니다. 컨테이너 내부 프로세스가 어떤 UID로 동작하는지 맞추지 않으면, 마운트는 멀쩡한데 애플리케이션만 쓰기 실패를 냅니다. 그래서 저는 앱 로그만 보지 않고, 호스트에서 직접 touch 테스트를 꼭 해봅니다.

touch /mnt/nas-test/.write-test
rm -f /mnt/nas-test/.write-test

이 테스트가 안 되면 애플리케이션 레벨로 내려가기 전에 파일 시스템 레벨부터 바로잡는 게 맞습니다.

서버와 클라이언트 사이에서 UID/GID가 어떻게 보이고, root_squash가 어떤 영향을 주는지 설명하는 이미지입니다.

6. ⚠️ 연결 끊김이 반복될 때 제가 체크하는 순서

권한 문제 말고, 잘 붙었다가 끊기는 유형도 은근 까다롭습니다. 이건 스토리지보다 네트워크 쪽 냄새가 나는 경우가 많습니다. 제가 삽질 좀 했습니다 ㅎㅎ 특히 스위치 바꾸고 VLAN 건드린 뒤부터 증상이 생겼던 적이 있었거든요.

1. ping으로 기본 지연과 손실이 있는지 확인합니다.
2. 대용량 복사 중 끊기는지 봅니다.
3. dmesg에서 NFS timeout, stale file handle 관련 메시지를 봅니다.
4. 스위치, 공유기, NAS 포트의 링크 속도/duplex를 확인합니다.
5. 가능하면 서버와 클라이언트의 시간 동기화(NTP) 상태도 확인합니다.

특히 stale file handle은 서버 쪽 공유 경로 구조가 바뀌었거나, 내부적으로 export 대상이 변경됐을 때 볼 수 있습니다. 폴더를 옮겼거나 NAS에서 공유를 다시 만들었는데 클라이언트가 예전 핸들을 들고 있으면 생기더라고요. 이럴 땐 무턱대고 재부팅보다, 언마운트 후 다시 마운트하는 쪽이 먼저입니다.

sudo umount /mnt/nas-test
sudo mount -a

# busy 상태면 어떤 프로세스가 잡고 있는지 확인
sudo lsof +D /mnt/nas-test

또 하나, Wi-Fi 환경에서 테스트할 때는 결과가 흔들릴 수 있습니다. NFS는 가능하면 유선이 낫습니다. 특히 백업 저장소나 VM 디스크처럼 지연에 민감한 워크로드는 더 그렇습니다. 이거 진짜 편하더라고요. 원인 추적할 때 변수 하나 줄이는 것만으로도 시간이 많이 아껴집니다.

7. NAS NFS 공유 정상 동작 검증: 읽기·쓰기·자동 마운트

설정 수정 후에는 꼭 검증을 남겨둬야 해요. 그냥 파일 하나 만들어보고 끝내면, 나중에 다시 같은 문제를 만났을 때 기준점이 없습니다. 저는 보통 아래 순서대로 봅니다.

1. 클라이언트에서 수동 마운트 성공 여부
2. 읽기, 쓰기, 삭제 테스트
3. 재부팅 후 자동 마운트 여부
4. 애플리케이션에서 실제 접근 가능 여부
5. 로그에 반복 에러가 없는지 확인

mount | grep nfs
stat /mnt/nas-test
touch /mnt/nas-test/check.txt
echo "nfs-ok" > /mnt/nas-test/check.txt
cat /mnt/nas-test/check.txt
rm -f /mnt/nas-test/check.txt

여기까지 통과하면 일단 기본기는 잡힌 겁니다. 다음으로는 실제 서비스에서 테스트해보면 됩니다. 예를 들어 미디어 서버라면 라이브러리 스캔, 백업 서버라면 테스트 백업, 컨테이너라면 볼륨 쓰기 테스트를 해보시면 됩니다. 겉으로는 멀쩡해도 실제 앱에서만 권한 문제가 나는 경우가 있어서, 이 단계는 꼭 하시는 걸 권합니다.

NFS 마운트 검증 단계에서 읽기, 쓰기, 삭제 테스트가 모두 통과한 상태를 보여주는 결과 이미지입니다.

8. 자주 묻는 질문 정리

Q1. SMB는 되는데 NFS만 안 되는 이유가 뭘까요?

인증 방식과 권한 해석 방식이 다르기 때문입니다. SMB는 계정 기반 접근이 익숙하고, NFS는 UID/GID와 export 정책 영향을 크게 받습니다. 그래서 같은 NAS에서도 SMB는 잘 되는데 NFS만 막힐 수 있습니다.

Q2. NFSv3와 NFSv4 중 무엇이 더 좋을까요?

정답은 환경마다 다릅니다. 일반적으로는 NFSv4를 먼저 시도하지만, 특정 NAS나 레거시 환경에서는 NFSv3가 더 단순하고 안정적으로 맞는 경우도 있습니다. 중요한 건 버전 논쟁보다 현재 환경에서 일관되게 동작하느냐입니다.

Q3. 권한이 꼬이면 777로 풀면 되나요?

급한 확인용으로는 잠깐 도움이 될 수 있어도, 근본 해결은 아닙니다. 결국 UID/GID, export 옵션, 서비스 계정 구조를 정리해야 다시 안 터집니다. 저도 예전에 777로 잠깐 열어놓고 잊었다가 나중에 더 크게 정리한 적이 있습니다.

Q4. Proxmox나 Docker에서 NAS NFS 공유를 붙일 때 팁이 있나요?

있습니다. 첫째, 서버 IP를 고정하세요. 둘째, 서비스가 어떤 UID/GID로 도는지 확인하세요. 셋째, 수동 마운트 검증 후 자동화로 넘어가세요. 이 세 가지만 지켜도 트러블슈팅 시간이 크게 줄어듭니다. 이전 글에서 다룬 리눅스 스토리지 마운트 점검 방법과 같이 보시면 더 이해가 쉬우실 겁니다. 다음 글에서는 NFS와 SMB를 홈랩 기준으로 비교해볼 예정입니다.

9. 마무리: 결국 NAS NFS 공유 문제는 순서가 답입니다

이번에 정리한 내용을 한 줄로 줄이면 이렇습니다. 서버 export 확인 → 클라이언트 수동 마운트 → UID/GID 점검 → 자동 마운트 검증. 저도 처음엔 이 순서를 모르고 여기저기 설정부터 바꾸다가 시간을 많이 썼습니다. 근데 디버깅 흐름을 정해두니까, 같은 증상이 와도 훨씬 덜 흔들리더라고요.

NAS NFS 공유는 익숙해지면 정말 편합니다. 리눅스 서버끼리 붙일 때 가볍고, 홈랩에서도 활용도가 높거든요. 대신 오류 해결은 감으로 하면 오래 갑니다. 증상 분류부터 하고, 권한 문제는 숫자 UID/GID로 확인하고, 네트워크 공유 계층까지 차근차근 보는 게 제일 빠릅니다.

연결 끊김, 권한 문제, 자동 마운트 오류를 점검하는 순서를 한 장으로 정리한 요약 이미지입니다.

혹시 지금 같은 문제로 막혀 계시면, 먼저 showmount -e, mount -t nfs, ls -ln 이 세 가지부터 확인해보세요. 여기서 절반은 갈립니다. 다음 글에서는 홈랩에서 자주 쓰는 NFS 마운트 옵션과 성능보다 안정성을 우선하는 설정 기준도 정리해보겠습니다. 그 글도 이어서 보시면 운영할 때 훨씬 덜 흔들리실 겁니다. 🎉

📚 함께 읽으면 좋은 글

• Docker on NAS로 Plex 미디어 서버 구축 가이드
• TrueNAS SCALE 1년 사용 후기: 홈랩 운영 교훈과 팁
• Synology vs QNAP NAS: 1년 사용 비용 및 ROI 분석
• TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크
• Proxmox OMV 연동: NAS 구축을 위한 최적의 조합 분석