소스는 실제 소유권 계층을 올바르게 설명합니다. 컨테이너가 마운트된 ZimaOS 폴더 안에 디렉터리를 만들 때 새 디렉터리는 일반적으로 상위 폴더가 자동으로 강제하도록 기대한 권한이 아니라 컨테이너 내부에서 실행 중인 프로세스의 사용자 ID와 umask 동작을 상속합니다.
따라서 모두에게 쓰기 권한이 있는 상위 디렉터리에서도 새로 생성된 하위 폴더가 root:root 소유이고 권한이 0755일 수 있습니다. 애플리케이션이 root로 실행되고 기본 umask를 사용하는 경우, 이미지가 PUID/PGID, 특정 컨테이너 사용자, setgid 그룹 상속, 기본 ACL 또는 다른 권한 모델을 지원하지 않는 한 root 소유의 하위 디렉터리가 생성되는 것은 정상입니다.
소스 예시는 마운트된 백업 폴더였습니다
사용자는 다음과 같은 경로를 설명했습니다.
/media/Daten/Backup이 경로에서 새로 생성된 하위 폴더가 다음과 같이 되었습니다.
root:root
drwxr-xr-x그러면 UID 999와 같은 비root 사용자는 새 하위 디렉터리의 파일을 읽을 수는 있지만 생성할 수 없습니다.
0777 상위 디렉터리가 하위 항목의 소유권을 강제하지는 않습니다
상위 디렉터리의 쓰기 권한은 컨테이너 프로세스가 하위 항목을 생성할 수 있도록 합니다. 파일 시스템 및 그룹 규칙이 해당 동작을 하도록 구성되어 있지 않다면, 하위 항목이 상위 디렉터리의 소유자나 그룹을 자동으로 상속하게 만들지는 않습니다.
일반적인 결과는 생성 프로세스의 UID/GID와 해당 프로세스의 umask에 따라 결정됩니다.
컨테이너 이미지가 지원하는 경우에만 PUID/PGID를 사용하세요
많은 LinuxServer 스타일 이미지는 PUID 및 PGID 환경 변수를 제공합니다. 다른 이미지는 이러한 변수를 완전히 무시하며 Docker의 user: 필드나 애플리케이션별 설정을 사용해야 합니다.
현재 IceWhale Syncthing 안내에서는 다음 명령으로 실제 ZimaOS 사용자 ID를 확인하라고 명시합니다.
id -u username
id -g username그런 다음 해당 값을 앱의 PUID/PGID 필드에 입력합니다.
현재 ZimaOS PUID/PGID 예시를 참조하세요.
umask는 생성 시 제거되는 권한 비트를 제어합니다
일반적인 umask인 022 환경에서 기본 모드 0777로 디렉터리를 생성하는 앱은 권한이 0755인 디렉터리를 만들게 됩니다. 그룹 공동 작업 방식에서는 애플리케이션이 지원하는 경우 다른 umask를 사용할 수 있습니다.
하나의 앱을 수정하기 위해 전역적으로 지나치게 허용적인 umask를 설정하지 마세요.
setgid는 새 하위 폴더에서 공유 그룹을 유지하는 데 도움이 될 수 있습니다
Linux 네이티브 파일 시스템에서는 공유 디렉터리에 setgid 비트를 설정하면 새로 생성되는 하위 항목이 해당 디렉터리의 그룹을 상속하도록 할 수 있습니다. 이는 여러 서비스나 사용자가 하나의 그룹을 통해 의도적으로 협업하는 경우 유용합니다.
이 설정은 생성 프로세스의 사용자 ID를 변경하지 않으며, 마운트 옵션을 통해 Unix 소유권을 에뮬레이션하는 NTFS/exFAT 마운트에서는 동일하게 동작하지 않을 수 있습니다.
기본 ACL은 더 명시적인 상속을 제공합니다
POSIX ACL을 지원하는 파일 시스템에서는 기본 ACL 항목을 통해 새 하위 항목이 받을 권한을 정의할 수 있습니다. 이는 각 백업 작업 후 재귀적으로 chmod를 반복 실행하는 것보다 깔끔한 경우가 많습니다.
현재 ZimaOS UI가 특정 저장 경로에 대해 완전한 ACL 작업 흐름을 제공하는지는 셸만 사용하는 구성을 전제로 하기 전에 확인해야 합니다.
소스 내용은 기존 ZimaOS 설정이 아니라 기능 요청이었습니다
작성자는 전역 PUID/PGID 제어, 상속 토글, umask 처리, setgid 지원 및 재귀적 수정 GUI를 요청했습니다. 해당 스레드에는 이러한 기능이 구현되었다고 확인하는 IceWhale의 응답이 없습니다.
요청 목록을 현재 Settings 옵션인 것처럼 제시하지 마세요.
디스크 전체를 재귀적으로 변경하기 전에 앱의 ID를 수정하세요
백업 앱이 반복적으로 root 소유 폴더를 다시 생성한다면, 각 작업 후 chown -R를 실행하는 것은 증상만 다루는 방법입니다. 먼저 컨테이너의 사용자 ID, 그룹 및 umask를 올바르게 구성한 다음 영향을 받은 트리만 복구하세요.
현재 ZimaOS 앱 설정에서는 볼륨 매핑과 앱 구성을 확인할 수 있지만, 정확한 권한 변수는 이미지에 따라 다릅니다.
마운트된 폴더 소유권 FAQ
쓰기 가능한 상위 디렉터리 아래의 하위 폴더가 왜 root:root가 될 수 있나요?
컨테이너 내부의 프로세스가 root로 해당 폴더를 생성했으며, 상위 디렉터리가 생성자의 ID를 자동으로 덮어쓰지 않기 때문입니다.
모든 Docker 이미지에서 PUID와 PGID가 작동하나요?
아니요. PUID와 PGID는 이미지별 환경 변수 관례이며, Docker의 보편적인 변수는 아닙니다.
소스에서 IceWhale이 전역 권한 상속 토글을 확인했나요?
아니요. 해당 스레드는 구현 확인이 없는 기능 요청입니다.
