갑자기 읽기 전용으로 바뀐 Docker 바인드 마운트 문제 해결 방법

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Docker가 읽기 전용 경로를 전달받거나 호스트 파일 시스템이 쓰기 작업을 더 이상 허용하지 않으면 Docker 바인드 마운트가 읽기 전용으로 변경됩니다.

바인드 마운트는 호스트 경로를 컨테이너 내부에 직접 노출하므로 컨테이너만으로는 기본 디스크, 파일 시스템, 마운트 플래그 또는 보안 정책 문제를 해결할 수 없습니다. 가장 안전한 복구 방법은 쓰기 작업을 중지하고, 컨테이너 마운트와 호스트 마운트를 비교하며, 읽기 전용 동작이 설정된 것인지 오류로 인해 발생한 것인지 확인한 다음, 애플리케이션을 다시 시작하기 전에 스토리지 상태를 복구하는 것입니다.

어떤 경로가 읽기 전용인지 확인

컨테이너 내부의 바인드 대상 경로에서 무해한 쓰기 작업을 테스트하고, 호스트의 소스 경로에서도 쓰기 작업을 수행하세요. 모든 권한 오류가 읽기 전용 파일 시스템을 의미한다고 가정하지 말고 정확한 오류를 기록해야 합니다.

Docker 포럼 사례에 따르면 읽기 전용 상위 바인드로 인해 Docker가 중첩 마운트 지점을 생성하지 못할 수 있습니다. 필요한 디렉터리를 읽기 전용 상위 파일 시스템에 생성할 수 없기 때문입니다.

호스트에서는 쓸 수 있지만 컨테이너에서는 쓸 수 없다면 Docker 마운트 옵션과 보안 제어를 확인하세요. 두 환경 모두 읽기 전용 파일 시스템 오류로 실패한다면 컨테이너 사용자를 계속 변경하지 말고 호스트 마운트와 스토리지 장치로 진단 범위를 옮겨야 합니다.

Docker에서 실제 적용된 마운트 플래그 확인

현재 Compose 파일만 확인하지 말고 실행 중인 컨테이너 설정을 검사하세요. 소스, 대상, 전파 모드, 그리고 :ro, 긴 형식, 오버라이드 파일 또는 배포 도구를 통해 마운트가 읽기 전용으로 표시되어 있는지 확인합니다.

Docker 클라이언트 이슈에는 런타임 설정이 의도한 읽기-쓰기 구성과 달라 마운트된 경로가 읽기 전용으로 표시된 사례가 기록되어 있습니다. 중요한 증거는 실행 중인 컨테이너에 적용된 실제 마운트 모드입니다.

마운트가 의도적으로 읽기 전용이라면 애플리케이션에 실제로 쓰기 작업이 필요할 때만 해당 플래그를 제거하세요. 선언을 변경한 후에는 컨테이너를 다시 생성해야 합니다. Compose 파일을 수정해도 기존 마운트가 소급하여 변경되지는 않기 때문입니다.

호스트가 파일 시스템을 읽기 전용으로 다시 마운트했는지 확인

호스트의 마운트 테이블, 커널 로그, 스토리지 로그 및 파일 시스템 상태에서 I/O 오류, 저널 오류, 체크섬 오류, 장치 재설정 또는 보호를 위한 재마운트가 발생했는지 확인하세요. 보호 기능이 활성화된 이유를 파악하기 전에 읽기-쓰기로 강제 재마운트하지 마십시오.

Unraid 지원 사례에서는 파일 시스템이 읽기 전용이 된 후 Docker 앱데이터에 문제가 발생했으며 Plex 디렉터리를 생성할 때도 오류가 발생했습니다. 이러한 패턴은 컨테이너 권한 설정이 아니라 호스트 파일 시스템 오류를 가리킵니다.

영향을 받는 컨테이너를 중지하고 진단 자료를 보존하세요. 플랫폼에서 지원하는 유지 관리 절차를 통해 디스크, 풀, 케이블, 파일 시스템 또는 저널을 복구한 다음, 데이터베이스나 미디어 컨테이너가 다시 쓰기 작업을 수행하도록 허용하기 전에 호스트 경로가 정상인지 확인합니다.

-15% OFF

중첩 및 겹치는 마운트 검사

대상 경로가 다른 마운트 디렉터리 안에 위치하는 모든 바인드 마운트와 이름 있는 볼륨을 나열하세요. 겹치는 마운트는 디렉터리를 가리거나 예상하지 못한 접근 동작을 상속하거나, Docker가 읽기 전용 상위 경로 아래에 마운트 지점을 생성하도록 요구할 수 있습니다.

Server Fault의 한 논의에서는 읽기-쓰기 마운트와 더 넓은 읽기 전용 마운트를 서로 연관된 컨테이너 경로에 겹쳐 설정하면 혼란스러운 결과가 발생할 수 있다고 설명합니다. 해당 주제는 이 배치의 다른 곳에서도 이미 사용되므로, 여기서 적용할 실용적인 규칙은 권한을 변경하기 전에 전체 대상 경로 트리를 파악하는 것입니다.

컨테이너를 시작하기 전에 필요한 호스트 디렉터리를 생성하고, 런타임에서 생성해야 하는 읽기 전용 상위 경로 아래에 쓰기 가능한 하위 경로를 마운트하지 마세요. Compose에서는 영구 경로를 명시적으로 유지합니다. 마운트 트리를 단순화한 후 컨테이너를 다시 생성하세요.

읽기 전용 상태를 권한 및 보안 정책과 구분

쓰기 테스트의 오류를 소스 디렉터리의 소유자, 모드, ACL, SELinux 레이블, AppArmor 프로필 및 컨테이너 사용자 ID와 비교하세요. 권한 거부와 읽기 전용 파일 시스템은 서로 다른 오류이며 서로 다른 복구 방법이 필요합니다.

스토리지 문제 해결 가이드에서는 읽기 전용 볼륨 문제를 마운트 플래그, 파일 시스템 오류, 보안 컨텍스트 및 스토리지 드라이버 문제로 분류합니다. 이러한 분류는 스토리지 계층의 읽기 전용 상태에 무작정 chmod 777을 적용하는 일을 방지하는 데 도움이 됩니다.

권한이 잘못된 경우 컨테이너에서 사용할 UID와 GID를 기준으로 호스트의 소유권 또는 ACL을 수정하세요. 파일 시스템 자체가 읽기 전용이라면 권한 변경도 실패하므로 파일 시스템 복구를 대신하는 방법으로 사용해서는 안 됩니다.

호스트 쓰기 테스트가 통과한 후에만 애플리케이션 재시작

호스트 경로에서 임시 파일을 생성하고, 동기화하고, 읽고, 삭제한 다음, 동일한 마운트 선언과 사용자를 적용한 단기 테스트 컨테이너에서도 같은 작업을 반복하세요. 재부팅 후에도 예상한 파일 시스템이 계속 마운트되어 있는지 확인합니다.

스토리지를 다시 쓸 수 있게 된 후에도 애플리케이션이 계속 재시작 루프를 반복한다면, 다음 단계로 컨테이너 재시작 종속성 찾기에 관한 ZimaSpace 가이드를 확인하세요.

호스트 파일 시스템이 정상이고, 실제 Docker 마운트가 의도한 대로 읽기-쓰기이며, 애플리케이션이 영구 파일을 업데이트할 수 있고, 지속적인 사용 중 새로운 I/O 또는 파일 시스템 오류가 발생하지 않을 때에만 복구가 완료된 것입니다.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.