새 ZimaOS 구성원에게 공유 인터페이스에서 읽기 및 쓰기 액세스 권한을 부여했는데도 “권한 거부”가 표시된다면, 스토리지 풀 전체에 즉시 재귀적 소유권 명령을 실행하지 마세요. 2026년 3월의 원본 스레드에서는 여러 소유권 가설을 테스트하고 초기화를 새로 수행했지만, 확정된 근본 원인에는 여전히 도달하지 못했습니다.
지속 가능한 문제 해결 방법은 ZimaOS/Samba 권한 계층과 기본 Linux 소유권 계층을 분리하는 것입니다. 먼저 작은 새 폴더에서 문제를 재현하고 관리자와 구성원의 액세스를 비교한 다음, 관련된 정확한 호스트 경로를 검사하세요.
UI에서 구성원 권한은 올바르게 표시되었습니다
관리자 계정은 데이터에 액세스할 수 있었지만, Andres라는 새로 만든 계정에는 읽기/쓰기 액세스 권한이 할당되었음에도 파일을 열 때 권한 오류가 발생했습니다.
현재 ZimaOS는 사용자별 Samba 권한을 지원합니다
현재 ZimaOS 문서에서는 구성원 액세스와 게스트 액세스를 구분하며, 관리자가 Samba 공유에 읽기 또는 읽기 및 쓰기 권한을 부여할 수 있습니다. 읽기 및 쓰기 권한이 있는 구성원은 기본 파일 시스템에 액세스할 수 있다는 전제하에 공유 내 파일을 다운로드, 업로드, 이름 변경 및 삭제할 수 있어야 합니다.
현재 ZimaOS 다중 사용자 Samba 설정을 기준으로 삼은 후, 오래된 스레드에서 복사한 셸 수준 수정 방법을 사용해야 합니다.
새 테스트 폴더에서 문제 재현
의도한 데이터 디스크에서 현재 Files 인터페이스를 통해 작은 테스트 폴더를 만드세요. 해당 폴더만 새 구성원에게 읽기 및 쓰기 권한으로 공유한 다음, 구성원의 자격 증명을 사용해 구성원의 클라이언트에서 연결하세요.
테스트 폴더는 작동하지만 마이그레이션했거나 오래된 디렉터리에서 실패한다면, 문제는 해당 경로 또는 소유권과 관련되어 있을 가능성이 높습니다. 새 UI에서 방금 만든 폴더에서도 실패한다면 문제의 범위가 더 넓은 것이므로, 레거시 파일 소유권이 아니라 계정, Samba 또는 ZimaOS 권한 문제일 가능성이 있는 것으로 보고 처리해야 합니다.
맹목적으로 수정하지 말고 진단 신호로 Linux 소유권을 활용하세요
스레드에서는 사용자 ID와 디렉터리 소유권을 조사한 결과 다음 경로 아래에 있는 항목이 /DATA/.media 서로 다른 Linux 사용자와 그룹이 소유하고 있었습니다. 따라서 마이그레이션된 데이터에서 소유권 불일치가 발생했을 가능성이 있습니다.
제안된 재귀적 chown 이 작업으로 애플리케이션이 관리하는 데이터 내부에 “Operation not permitted” 오류가 많이 발생했습니다. 이는 광범위한 시스템 또는 AppData 트리 전체에 하나의 소유권 명령을 적용해서는 안 된다는 경고입니다. 소유권을 재귀적으로 변경하면 특정 UID와 GID를 필요로 하는 컨테이너나 서비스가 중단될 수 있습니다.
다음을 사용하세요. id, ls -ld, 그리고 정확히 어느 경로에서 문제가 발생하는지 파악하기 위한 작은 테스트 파일을 사용하세요. 관련 없는 애플리케이션 디렉터리는 변경하지 마세요.
공장 초기화는 확인된 해결책이 아니었습니다
재포맷하고 재설치한 후에도 작성자는 멤버 권한 오류가 계속 발생한다고 보고했습니다. 이 결과는 중요합니다. 사용자 액세스 문제의 일반적인 해결책으로 파괴적인 초기화를 권장하지 마세요.
문제 신고 전에 수집할 정보
현재 ZimaOS를 통해 새로 만든 폴더에서도 새로 생성한 멤버에게 계속 오류가 발생한다면 ZimaOS 버전, 공유 경로, 멤버 권한 설정, 클라이언트 운영 체제, 정확한 오류 메시지, 관리자 액세스 작동 여부를 기록하세요. 또한 다음 명령의 출력도 기록하세요. id 관련 계정에 대해 실행하고 ls -ld 영향을 받은 경로에만 적용합니다.
그 증거는 또 다른 광범위한 소유권 변경보다 더 유용합니다. 원본 스레드는 클린 설치 재현을 예상 밖의 현상으로 보고 추가 조사가 필요하다고 여기는 분위기로 끝났으며, 검증된 한 줄짜리 해결책으로 끝난 것이 아닙니다.
