기술 · 실용 가이드

NFS “Stale file handle”? 다시 마운트하기 전에 바뀐 서버 ID를 입증하세요

ESTALE은 저장된 참조가 더 이상 유효한 객체를 가리키지 않는다는 뜻입니다. 마운트 시 export 실패와 작업 중 객체 무효화를 구분하고 서버 경계를 고친 뒤 한 클라이언트에서 검증하세요.

작성 Watch at Ease News · 3 분 읽기발행 2026. 10. 19. 오전 1:45 UTC

Linux는 ESTALE을 Stale file handle로 정의하며 NFS 외 파일시스템에서도 생길 수 있습니다. NFSv4 persistent handle은 객체 삭제나 파일시스템 비가용 시 stale이 됩니다.

1. 사건을 고정하고 writer 보호

실패 명령, 경로, 클라이언트, 서버, NFS 버전, 최초 시각과 커널/서비스 로그를 저장하세요. 해당 마운트 writer를 멈추고 광범위한 lazy unmount나 flush부터 하지 마세요.

클라이언트 findmnt를 정상 노드와 비교하고 서버 backing mount, exportfs -v, storage/NFS log를 변경 전에 저장하세요.

mount 자체가 ESTALE이면 요청 export와 live table을 조사하세요. 기존 mount의 ls, open, chdir, 앱이 실패하면 최초 경로와 이웃 객체를 시험하세요.

삭제 후 재생성, 복원, dataset 교체, failover 뒤에는 같은 이름도 새 객체이므로 옛 참조가 무효일 수 있습니다.

export 경로가 빠진 mount 아래 빈 directory가 아니라 의도한 filesystem인지 확인하세요. UUID/device, fsid, options와 rename/restore/mover/migration을 비교하세요.

RFC 7530은 삭제 객체에 stale 오류를 요구하며 filesystem이 server namespace에서 사라질 때도 stale일 수 있습니다. 재부팅은 시간 단서이지 원인 증명이 아닙니다.

backing storage를 먼저 복구하고 export path/identity를 바로잡으세요. live table이 원인일 때만 동기화하세요. 광범위한 unexport/flush는 다른 client와 NFSv4 state에 영향을 줍니다.

다른 사례만 보고 subtree_check, fsid, protocol version, mount option을 바꾸지 말고 한 번에 한 가설만 시험하세요.

namespace가 안정되면 한 client를 멈추고 stale cwd를 벗어나 정확한 mount를 안전하게 해제 후 재마운트하세요. 멈출 수 없는 process를 lazy detach로 숨기지 마세요.

fresh lookup, 대표 read, 허용된 controlled write, metadata와 application transaction을 확인하고 다른 client와 log를 비교한 뒤 나머지를 복구하세요.