앱 데이터를 복사한 후 컨테이너 파일 소유자가 변경되는 이유 EIF

숫자 UID/GID 값이 보존되지 않거나 대상 런타임이 해당 값을 다시 매핑하거나 덮어쓰면 복사 후 컨테이너 파일 소유자가 변경됩니다.

홈 NAS에서는 소유권이 숫자로 저장되지만 각 환경이 서로 다른 계정 데이터베이스를 통해 해당 숫자를 확인하기 때문에, 동일한 파일이 호스트에서는 한 사용자 이름으로, 컨테이너 내부에서는 다른 사용자 이름으로 표시될 수 있습니다. GUI, SMB 공유, 아카이브, 루트 셸, 마이그레이션 도구 또는 컨테이너 엔트리포인트를 통해 복사할 때도 소유권이 바뀔 수 있습니다. 먼저 숫자로 된 ID를 진단한 다음, 애플리케이션 데이터 트리 전체의 권한을 변경하기 전에 복사 동작, 런타임 사용자 설정, 시작 스크립트, 사용자 네임스페이스, 네트워크 파일 시스템 매핑을 구분해 확인하세요.

사용자 이름을 비교하기 전에 숫자 UID와 GID를 비교하세요

이름만 확인하지 말고 숫자로 표시된 소유권을 사용해 소스와 대상을 검사하세요. 호스트와 컨테이너 내부에서 대표 파일 하나와 해당 상위 디렉터리에 대해 UID, GID, 모드, ACL, 확장 속성 및 파일 시스템을 기록하세요.

Docker 바인드 마운트는 호스트 파일을 다른 사용자 데이터베이스를 사용하는 프로세스에 노출합니다. Docker 커뮤니티의 권한 관련 논의에서는 사용자 이름만 일치시키기보다 숫자 UID/GID를 일치시키는 것이 안정적인 접근에 필요한 이유를 설명합니다.

숫자가 동일하지만 표시되는 이름이 다르다면 소유권 자체는 변경되지 않았을 수 있습니다. 데이터를 재귀적으로 다시 작성하지 말고 문서나 계정 매핑을 수정하세요. 숫자가 다르다면 해당 증거를 보존한 채 복사 및 런타임 단계를 계속 조사하세요.

복사 과정에서 소유권이 보존되었는지 다시 생성되었는지 확인하세요

호스트 파일 관리자, cp, rsync, tar 아카이브, SMB/NFS 클라이언트, 백업 복원, Docker 복사 명령 또는 임시 마이그레이션 컨테이너 중 정확히 어떤 경로로 복사했는지 기록하세요. 각 방법은 소유자, 그룹, ACL 및 확장 속성에 대해 서로 다른 기본값을 사용합니다.

루트로 실행한 복사는 명시적인 아카이브 옵션을 사용하면 숫자 소유권을 보존할 수 있지만, 다른 도구는 복사를 수행하는 계정의 소유자로 모든 대상 파일을 만들 수 있습니다. 최근 컨테이너 마이그레이션 문제에서는 대상 UID가 애플리케이션의 런타임 ID와 달라 복사한 애플리케이션 데이터를 읽을 수 없게 된 사례를 보여 줍니다.

작은 테스트 디렉터리 하나로 작업을 반복하고 애플리케이션을 시작하기 직전에 소유권을 확인하세요. 숫자가 이미 잘못되어 있다면 복사 방법이나 복원 옵션을 수정하세요. 시작 후에만 변경된다면 복사 결과는 그대로 두고 컨테이너 엔트리포인트를 조사하세요.

컨테이너 런타임 사용자를 호스트 저장소 소유자와 일치시키세요

실행 중인 컨테이너 내부의 유효 사용자와 바인드 마운트된 애플리케이션 데이터 디렉터리의 숫자 소유자를 확인하세요. Compose의 user:, 보조 그룹, 플랫폼의 PUID/PGID 변수 및 이미지별 계정 설정도 확인하세요.

비루트 컨테이너 사용자로 실행한다고 해서 다른 숫자 ID가 소유한 호스트 디렉터리에 대한 접근 권한이 자동으로 부여되지는 않습니다. Docker 포럼의 한 사례에서는 디렉터리를 모든 사용자에게 쓰기 가능하게 만드는 대신 컨테이너 사용자와 호스트 권한을 일치시키는 방식으로 문제의 경계를 해결했습니다.

애플리케이션에 사용할 안정적인 소유권 모델 하나를 선택하고 Compose에 문서화하세요. 공유 접근에 필요한 그룹만 추가하세요. chmod 777은 사용하지 마세요. 이는 ID 불일치를 가리고 격리를 약화시키며 향후 생성되는 파일에 의도한 소유자를 보장하지 않습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

엔트리포인트가 시작 시 소유권을 변경하는지 확인하세요

많은 이미지는 잠시 루트로 시작해 누락된 디렉터리를 만들고, 설정된 UID/GID를 적용한 뒤, 권한을 내리기 전에 소유권을 재귀적으로 변경합니다. 이 동작 때문에 첫 컨테이너 시작 후 올바르게 복사된 파일의 소유권이 저절로 바뀐 것처럼 보일 수 있습니다.

컨테이너 런타임과 이미지는 소유권을 변경하는 마운트 동작도 제공할 수 있습니다. Podman 이슈에서는 :U 옵션이 소스 소유권을 다시 작성할 수 있음을 설명하며, 엔트리포인트 스크립트도 애플리케이션 시작 중 유사한 재귀 변경을 수행할 수 있습니다.

로그를 표시한 상태로 컨테이너를 한 번 시작하고 작은 테스트 하위 트리를 모니터링하세요. 엔트리포인트와 이미지 릴리스 노트에서 chown, 사용자 마이그레이션, PUID/PGID 및 권한 수정 단계를 검색하세요. 이미지가 안정적인 대안을 지원하는 경우에만 해당 동작을 비활성화하거나 범위를 줄이세요.

Rootless Docker, 사용자 네임스페이스 및 네트워크 파일 시스템을 고려하세요

Rootless Docker와 사용자 네임스페이스 매핑은 컨테이너 ID를 다른 호스트 ID 범위로 변환합니다. NFS, CIFS 및 일부 NAS 마운트 옵션은 별도로 루트를 매핑하거나 모든 파일에 설정된 UID와 GID를 강제할 수 있습니다.

Rootless Docker 권한 보고서에서는 컨테이너 ID가 호스트의 보조 ID 범위를 통해 매핑되기 때문에 파일이 예상과 다른 소유권으로 표시되는 현상을 다룹니다. 진단의 단서는 일반적인 복사 실패가 아니라 사용자 네임스페이스 소유권 매핑입니다.

데이터 경로가 로컬인지, NFS인지, CIFS인지, FUSE인지 또는 다른 마운트 파일 시스템인지 확인한 다음 UID/GID, 루트 스쿼시 및 ACL 동작을 기록하세요. 호스트와 컨테이너에서 각각 소유권이 적용된 파일을 생성하는지 테스트하세요. 서버 측 ID 정책을 이해하기 전에는 네트워크 공유에 재귀적으로 chown을 실행하지 마세요.

애플리케이션의 기준 ID를 사용해 소유권을 복구하세요

애플리케이션을 중지하고 현재 메타데이터를 백업한 다음, 이미지가 요구하는 정확한 UID, GID, 디렉터리 모드, 파일 모드, ACL 및 보안 레이블을 정의하세요. 공유 미디어나 관련 없는 데이터 세트는 제외하고 애플리케이션이 소유한 경로만 수정하세요.

올바른 소유권인데도 쓰기가 허용되지 않을 때는 ZimaSpace의 권한 오류와 읽기 전용 마운트 구분 가이드를 다음 확인 단계로 참고하세요.

컨테이너를 다시 시작하고 실제 서비스 사용자로 테스트 파일 하나를 생성, 수정 및 삭제하세요. 그런 다음 컨테이너를 다시 생성하고 테스트를 반복하세요. 복사, 시작, 재부팅 및 컨테이너 재생성 후에도 소유권이 안정적으로 유지되고, 광범위한 권한 예외 없이 애플리케이션이 읽고 쓸 수 있을 때만 복구가 완료된 것입니다.