파일을 NAS로 이동한 후 파일 권한이 깨지는 이유는 무엇인가요?

파일은 컴퓨터, 외장 드라이브 또는 다운로드 폴더에서는 정상 작동하다가 NAS로 이동 후 읽기 전용이 되거나 앱에서 보이지 않거나 접근할 수 없게 될 수 있습니다. 이는 보통 파일 데이터가 손상되었다는 의미가 아닙니다. 파일이 다른 소유권과 권한 모델을 가진 새 파일시스템에 들어갔다는 뜻입니다.

장치 간 이동은 보통 복사 후 원본 삭제로 수행됩니다. NAS는 연결된 SMB 또는 NFS 신원, 대상 폴더 ACL, UID 및 GID 값, umask, 컨테이너 사용자, 서버 측 생성 규칙을 사용해 새 파일을 만듭니다. 문제를 가장 빠르게 해결하는 방법은 누가 파일을 만들었는지, 현재 누가 소유하는지, 어떤 사용자나 프로세스가 거부당하는지 확인하는 것입니다.

파일을 NAS로 이동하면 보통 새 파일이 생성됩니다

폴더를 NAS로 드래그하는 것은 Windows 탐색기나 Finder에서 일반적인 이동처럼 보일 수 있습니다. 그러나 내부적으로 원본 디스크와 NAS는 별개의 파일시스템입니다. 클라이언트는 원본 데이터를 읽고 새 대상 객체를 생성한 후 전송이 성공하면 원본을 삭제합니다.

이는 같은 파일시스템 내 두 폴더 간 파일 이동과 다릅니다. 후자의 경우 시스템은 파일의 디렉터리 위치만 업데이트할 수 있습니다. 마이크로소프트의 복사 및 이동 동작 설명에 따르면 다른 볼륨으로 복사된 객체는 새 폴더의 권한을 상속받으며, 같은 볼륨 내 이동은 보통 기존 권한을 유지합니다.

이 구분은 “잘라내기 및 붙여넣기”가 NAS로 전송 후 소유권, ACL 항목 또는 확장 속성이 동일하게 유지된다는 보장을 하지 않는 이유를 설명합니다. 대상 시스템은 단순히 원본 파일시스템 객체를 이동하는 것이 아닙니다.

대상 ACL이 새 파일이 상속받을 권한을 결정합니다

모든 새로 복사된 파일이 동일한 예상치 못한 권한을 받는 경우, 부모 디렉터리가 보통 원본 파일보다 더 중요합니다. 대상은 상속된 ACL 항목, 기본 POSIX ACL, NFSv4 ACL 플래그 또는 NAS 전용 권한 사전 설정을 가질 수 있습니다.

예를 들어, 공유 폴더는 새 파일이 가족 그룹, 미디어 그룹 또는 특정 SMB 계정에 대한 접근 권한을 상속받도록 구성될 수 있습니다. 상속 플래그가 없으면 반대 결과가 발생할 수 있습니다: 사용자는 데이터셋 루트에는 접근할 수 있지만 그 안의 새 파일에는 접근할 수 없게 됩니다.

TrueNAS 스타일 권한 시스템은 POSIX와 NFSv4/SMB ACL 모델을 구분합니다. 중요한 점은 NFSv4 및 SMB ACL 상속이 새 파일과 폴더를 제어할 수 있다는 것이며, POSIX 기본값과 데이터셋 경계는 다르게 동작합니다. 개별 파일을 변경하기 전에 대상 폴더의 ACL과 상속 플래그를 검사하세요.

NAS는 연결된 SMB 계정을 사용합니다.

Windows 또는 macOS 컴퓨터가 SMB를 통해 파일을 복사할 때, NAS는 일반적으로 클라이언트 컴퓨터의 로컬 사용자 ID를 보존하지 않습니다. SMB 공유에 인증된 계정이나 해당 세션에 매핑된 계정으로 대상 파일을 생성합니다.

이것이 원본 PC의 Windows 사용자가 소유한 파일이 kenneth , nasuser , guest 전송 후 다른 NAS 측 ID일 수 있습니다. 저장된 SMB 자격 증명은 한 컴퓨터가 다른 컴퓨터와 다른 소유자로 파일을 생성하게 할 수도 있습니다.

데스크톱 로그인 사용을 가정하지 말고 활성 SMB 사용자 이름을 확인하세요. 공유 연결을 끊고 필요 시 오래된 자격 증명을 삭제한 후, 파일을 소유하거나 관리해야 하는 NAS 계정으로 다시 연결하세요.

공유 접근과 파일 접근은 별개의 권한 계층입니다.

사용자가 SMB 공유를 열고 폴더를 탐색할 수 있어도 파일을 편집, 이름 변경 또는 삭제할 수 없을 수 있습니다. 이는 네트워크 공유에 접근 가능함을 의미하지만, 파일시스템이 요청된 작업을 허용했음을 증명하지는 않습니다.

공유 수준 규칙은 SMB 또는 NFS 클라이언트가 공유에 접근할 수 있는지, 그리고 연결이 읽기 전용인지 읽기/쓰기인지 결정합니다. 그 후 기본 파일시스템이 각 파일과 디렉터리에 대해 소유자, 그룹, 모드 비트, ACL 항목 및 상속 규칙을 평가합니다.

두 계층 모두 문제를 해결하세요. 읽기/쓰기로 표시된 공유는 쓰기를 거부하는 파일시스템 ACL을 무시할 수 없으며, 관대한 파일시스템 모드는 SMB 계정이 공유 구성에 의해 제한될 때 도움이 되지 않습니다.

Windows 스타일 ACL과 POSIX 모드는 완벽하게 일치하지 않습니다.

Windows 권한이 여러 사용자 및 그룹, 명시적 허용 및 거부 항목, 상속 플래그, 읽기, 쓰기, 삭제 및 수정에 대한 별도의 권한을 포함할 수 있지만, 전통적인 POSIX 모드 비트는 소유자, 그룹 및 기타로 접근을 제한합니다.

Samba 및 NAS 운영체제는 이러한 모델 간 변환을 수행해야 합니다. Windows 보안 패널은 ls -l 단순화된 표현만 표시합니다. 반대로, chmod SMB 클라이언트가 기대하는 Windows 스타일 ACL을 올바르게 재구성하지 않고 모드 비트를 변경할 수 있습니다.

NAS 데이터셋이 NFSv4 또는 SMB ACL을 사용하는 경우, NAS 인터페이스나 ACL 인식 명령어를 통해 전체 ACL을 검사하세요. 파일이 rwxrwx--- 전체 권한 이야기를 알려줍니다.

UID 및 GID 불일치가 Linux, NFS 및 앱에 미치는 영향

Linux 시스템은 보통 숫자 사용자 ID와 그룹 ID로 소유권을 결정합니다. 사용자 이름은 그 숫자에 연결된 라벨일 뿐입니다.

두 시스템 모두 media 한쪽은 UID 1000을 사용하고 다른 쪽은 UID 1001을 사용합니다. Linux와 NFS에 이들은 서로 다른 ID입니다. UID 1000이 소유한 파일은 UID 1001로 실행되는 애플리케이션에서 접근할 수 없을 수 있으며, 두 사용자 이름이 동일해 보여도 마찬가지입니다.

NAS, 호스트, 클라이언트 및 애플리케이션에서 숫자 값을 확인하세요:

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

표시된 이름만 비교하지 말고 숫자를 비교하세요. 여러 시스템이 동일 스토리지에 쓰기 필요가 있다면 필요한 UID/GID 값을 일치시키거나 올바른 권한을 가진 공유 그룹을 만드세요.

SMB와 NFS는 동일 데이터셋에 대해 서로 다른 사용자로 쓸 수 있습니다

권한 문제는 SMB 클라이언트와 NFS 클라이언트가 동일 디렉터리에 모두 쓰기 권한을 가질 때 점진적으로 나타나는 경우가 많습니다. SMB를 통해 업로드된 파일은 한 NAS 사용자에 속할 수 있지만, NFS를 통해 생성된 파일은 다른 시스템의 숫자 UID를 가질 수 있습니다.

두 프로토콜은 서로 다른 ACL 및 ID 매핑 규칙을 적용할 수도 있습니다. 결과적으로 폴더 내 파일이 사용자에게는 동일해 보여도 소유자, 그룹, 마스크 또는 상속된 항목이 다를 수 있습니다.

가능하면 하나의 기본 쓰기 프로토콜을 선택하세요. SMB와 NFS가 데이터셋을 공유해야 할 경우, 숫자 ID, 공유 그룹, 기본 ACL, umask 값 및 생성 동작을 일치시킨 후 프로덕션 데이터를 배치하세요.

Docker 컨테이너는 또 다른 사용자 ID를 추가합니다

파일은 SMB를 통해 읽을 수 있지만 Plex, Jellyfin, Nextcloud, 다운로드 프로그램 또는 백업 컨테이너에서는 접근할 수 없을 수 있습니다. Docker는 올바른 경로를 마운트할 수 있지만 컨테이너 내부 프로세스가 읽기 또는 쓰기 권한이 없을 수 있습니다.

컨테이너 프로세스는 자체 UID와 GID로 실행됩니다. 해당 ID가 마운트된 NAS 경로의 소유자나 허용된 그룹과 일치하지 않으면 애플리케이션은 권한 거부를 받습니다. 권한 거부됨. 볼륨 마운트는 디렉터리를 보이게 할 뿐이며, 파일 시스템 권한을 우회하지 않습니다.

일반적인 해결책은 컨테이너 UID와 GID를 마운트된 볼륨을 사용할 수 있는 권한과 일치시키는 것입니다. Compose 파일에 표시된 PUID 또는 PGID 필드에만 의존하지 말고 실제 프로세스 ID를 확인하세요:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "쓰기 가능"

한 컨테이너는 파일을 생성할 수 있지만 다른 컨테이너는 읽을 수 없습니다

이 문제는 미디어 자동화 스택에서 자주 발생합니다. 다운로드 컨테이너가 완료된 파일을 성공적으로 작성하지만, 미디어 서버가 이를 스캔하지 못하거나 정리 프로그램이 이름을 바꾸지 못하는 경우입니다.

애플리케이션은 서로 다른 UID/GID 값이나 다른 umask를 사용할 수 있습니다. 다운로드하는 사용자가 파일을 생성할 때 600, 오직 소유자만 읽고 쓸 수 있습니다. 예를 들어 640 그룹 읽기를 허용하지만 두 애플리케이션이 올바른 그룹을 공유할 때만 가능합니다.

공유 애플리케이션 디렉터리의 경우, 계획된 소유자 그룹을 사용하고 필요한 애플리케이션 ID를 해당 그룹에 추가하며, 그룹에 필요한 접근 권한을 부여하는 umask를 선택하세요. 다운로드하는 사용자가 제한된 모드로 새 파일을 계속 생성한다면 기존 파일만 수정하는 것은 도움이 되지 않습니다.

Umask 및 서버 생성 규칙이 새 권한을 제어합니다.

기존 파일은 작동하지만 새 파일이 모두 접근 불가능하다면, 생성 과정이 원인일 가능성이 큽니다. 각 프로그램은 요청된 파일 모드로 시작하며, umask가 파일 생성 전에 선택된 권한을 제거합니다.

Samba는 또한 다음과 같은 설정을 사용할 수 있습니다 생성 마스크, 디렉터리 마스크, 사용자 강제 지정, 또는 그룹 강제 지정NAS 인터페이스는 권한 템플릿, 공유 폴더 사전 설정 또는 상속 옵션 뒤에 이를 숨길 수 있습니다.

Windows SMB, macOS SMB, NAS 파일 관리자, NFS 및 각 관련 컨테이너를 통해 테스트 파일을 하나씩 생성하세요. 결과로 나온 소유자, 그룹, 모드 및 ACL을 비교하면 어떤 생성 경로가 권한 문제를 일으키는지 빠르게 알 수 있습니다.

다양한 전송 도구는 서로 다른 메타데이터를 보존합니다.

Finder, Windows 탐색기, NAS 웹 인터페이스, cp, 그리고 rsync 동일한 결과를 보장하지 않습니다. 일부는 타임스탬프를 보존하고, 일부는 POSIX 모드를 유지하며, 다른 일부는 단순히 대상 규칙에 따라 새 파일을 생성합니다.

마이그레이션 방법을 선택하기 전에 어떤 속성이 유지되어야 하는지 결정하세요:

• 파일 내용 및 디렉터리 구조
• 수정 시간
• POSIX 권한
• 소유자 및 그룹
• ACL 항목
• 확장 속성
• 심볼릭 링크

일반 가정 문서나 미디어 파일의 경우, NAS에 존재하지 않는 소스 컴퓨터 계정을 보존하기보다 대상 상속이 더 나을 수 있습니다. 애플리케이션 데이터, 리눅스 홈 디렉터리 또는 서버 마이그레이션의 경우 소유권과 ACL 메타데이터 보존이 필수일 수 있습니다.

Rsync는 기본 명령 하나로 모든 속성을 보존하지 않습니다.

Rsync는 제어된 NAS 마이그레이션에 유용하지만, 결과는 옵션, 실행 사용자 권한, 소스 및 대상 파일시스템의 기능에 따라 달라집니다.

아카이브 모드는 허용되는 경우 모드, 타임스탬프, 그룹 및 소유권을 포함한 일반 메타데이터를 보존합니다. 마이그레이션 시 rsync로 권한, ACL 및 확장 속성을 보존해야 할 경우 추가 옵션이 필요합니다. 일반적인 리눅스 간 테스트는 다음과 같이 사용할 수 있습니다:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

다음은 -A 옵션은 ACL을 보존하고 -X 양쪽이 지원할 때 확장 속성을 보존합니다. --numeric-ids NAS에 유효한 계정이 없는 숫자 소유자를 보존하는 것은 피하려는 불일치를 재현할 수 있으므로 신중히 사용해야 합니다.

SMB 마운트된 Rsync 대상은 NAS 파일시스템처럼 동작하지 않을 수 있습니다

컴퓨터에서 로컬로 마운트된 SMB 공유로 rsync를 실행하는 것은 NAS 파일시스템에 직접 SSH로 rsync를 실행하는 것과 항상 동일하지 않습니다. SMB 계층은 소유자를 매핑하거나 ACL을 변환하거나 속성 설정 시도를 거부할 수 있습니다.

SMB 복사를 수행하는 사용자는 rsync가 요청하더라도 임의 소유권을 할당할 권한이 없을 수 있습니다. 대상 파일시스템은 출처와 다른 ACL 모델을 지원할 수도 있습니다.

작고 대표적인 디렉터리를 먼저 테스트하세요. 전송 후 클라이언트에 마운트된 공유를 통해서만이 아니라 NAS에서 직접 파일을 검사하세요. 전체 데이터셋을 마이그레이션하기 전에 소유권, 모드, ACL, 확장 속성, 애플리케이션 접근을 확인하세요.

NAS 권한 사전 설정은 단순 모드 비트를 무시할 수 있습니다

일부 NAS 시스템은 전통적인 소유자/그룹/기타 모드뿐 아니라 데이터셋 ACL 템플릿과 확장 메타데이터를 통해 접근을 관리합니다. 이로 인해 수동으로 chmod 성공한 것처럼 보이지만 SMB나 애플리케이션이 계속 접근을 거부할 수 있습니다.

데이터셋은 새 파일 생성 시나 관리 인터페이스를 통해 권한을 편집할 때 상속된 규칙을 다시 적용하도록 구성될 수도 있습니다. GUI로 관리되는 ACL과 반복적인 명령줄 변경을 혼합하면 일관성 없는 상태가 발생할 수 있습니다.

하나의 권한 모델을 선택하고 일관되게 관리하세요. 데이터셋이 SMB/NFSv4 ACL로 구성된 경우, POSIX 모드 명령어로 구조를 반복해서 교체하지 말고 NAS ACL 편집기나 ACL 인식 도구를 사용하세요.

NAS 재설치가 반드시 데이터 권한을 초기화하지는 않습니다

권한은 보통 파일과 파일시스템 데이터셋에 속하며, 단순히 NAS 운영체제 구성에만 속하지 않습니다. 따라서 부트 시스템을 재설치해도 가져온 스토리지 풀에 동일한 접근 불가능한 소유권 및 ACL 항목이 남아 있을 수 있습니다.

TrueNAS 커뮤니티 사례는 파일시스템 권한이 스토리지 풀에 계속 연결되어 있으며 올바른 사용자 및 접근 구성과 일치해야 함을 보여줍니다. 또한 의도한 식별 모델을 먼저 이해하지 않고 대규모 재귀적 변경을 수행할 때의 위험성도 보여줍니다.

서비스를 재설치하거나 재구성하기 전에 데이터셋 소유자, 그룹, ACL 및 애플리케이션 사용자를 점검하세요. 데이터는 온전할 수 있으며 접근 규칙만 올바르게 복원하면 됩니다.

재귀적 chmod 777이 진정한 해결책이 아닌 이유

수천 개의 파일이 접근 불가능해질 때, chmod -R 777 접근 권한을 빠르게 복원하는 방법처럼 보입니다. 소유자, 그룹 및 모든 로컬 신원에 읽기, 쓰기, 실행 권한을 부여합니다.

이 방법은 개인 데이터를 노출시키고, 관련 없는 서비스가 파일을 수정하게 하며, 일반 문서에 실행 권한을 설정하고, 신중하게 상속된 ACL 구조를 손상시킬 수 있습니다. 또한 잘못된 소유자, 불일치하는 컨테이너 UID, 누락된 그룹 멤버십, 깨진 SMB 신원 매핑을 수정하지 않습니다.

대신 의도된 접근 모델을 사용하세요: 올바른 소유자와 공유 그룹을 설정하고, 적절한 ACL을 재구성하며, 디렉터리와 파일 모드를 별도로 설정하고, 향후 상속 및 umask 설정을 수정하세요. 재귀적 변경을 적용하기 전에 작은 폴더에서 테스트하세요.

신원에서부터 권한 복구

수정하려는 명령보다 거부된 사용자 또는 프로세스부터 시작하세요. 사람 SMB 사용자, 미디어 서버, 백업 컨테이너는 서로 다른 접근 수준이 필요할 수 있습니다.

영향받은 각 워크플로우에 대해 기록하세요:

• 접근을 시도하는 사용자 또는 프로세스
• 적용 가능한 경우 숫자 UID 및 GID
• 사용된 프로토콜 또는 마운트
• 파일의 현재 소유자 및 그룹
• 전체 ACL 및 상속된 항목
• 실제로 필요한 접근: 읽기, 생성, 수정 또는 삭제

그런 다음 잘못된 계층만 수정하세요. 사용자를 허용된 그룹에 추가하거나, 소유권을 수정하거나, ACL을 복구하거나, 컨테이너 UID를 맞추거나, 생성 규칙을 업데이트하세요. 워크플로우에 필요한 것보다 더 넓은 접근 권한을 부여하지 마세요.

계층별 문제 해결 순서 따르기

공유 ACL, 컨테이너 신원, NFS 내보내기, 파일 모드를 동시에 변경하면 유용한 증거가 사라집니다. 권한 계층을 하나씩 테스트하세요.

영향받은 파일 하나와 사용자 또는 애플리케이션 하나로 시작하세요. 작은 사례가 작동하면 정상 워크플로우를 통해 새 파일을 만들고 수정이 문제 재발을 방지하는지 확인하세요.

대규모 NAS 마이그레이션 전에 권한 문제를 예방하세요

수십만 개 파일의 권한을 복구하는 것은 마이그레이션 전에 접근 모델을 테스트하는 것보다 훨씬 어렵습니다. 최종 데이터셋에 계획된 동일한 ACL과 애플리케이션 구성을 가진 작은 대상 폴더를 만드세요.

여러 파일 유형, 중첩된 디렉터리, 읽기 전용 파일, 실행 스크립트, 확장 속성이 있는 파일을 복사하세요. SMB, NFS, NAS 인터페이스, 백업 소프트웨어, 관련 컨테이너 등 필요한 각 경로에서 테스트하세요.

새 파일이 일관되게 올바른 소유자, 그룹, ACL, 애플리케이션 접근 권한을 받을 때만 전체 마이그레이션을 시작하세요. 기존 데이터에 대한 재귀적 소유권 또는 권한 변경을 적용하기 전에 스냅샷이나 백업을 유지하세요.

최종 요점

파일 권한이 NAS로 데이터를 이동한 후 깨지는 이유는 전송 시 보통 새 파일 시스템 객체가 생성되기 때문입니다. 이 객체들은 전송에 사용된 NAS 계정, 대상 ACL, UID/GID 값, umask, 프로토콜 매핑, 애플리케이션 또는 컨테이너 아이덴티티에 의해 관리됩니다.

chmod 777로 시작하지 마세요 chmod 777먼저 세 가지 질문에 답하세요: 누가 파일을 생성했는지, 현재 누가 소유하고 있는지, 어떤 아이덴티티가 거부당하는지. 그런 다음 공유 접근, 파일 시스템 ACL, 상속, 컨테이너 ID, 향후 생성 규칙을 점검하세요.

성공적인 복구는 두 가지를 해야 합니다: 기존 파일에 적절한 접근 권한을 복원하고, NAS에 복사, 다운로드 또는 생성되는 다음 파일이 자동으로 올바른 권한을 받도록 보장하는 것입니다.

자주 묻는 질문(FAQ)

복사된 파일이 NAS 폴더의 권한을 상속하는 이유는 무엇인가요?

NAS로의 전송은 보통 다른 파일 시스템에 새 파일을 생성합니다. 새 객체는 일반적으로 대상 폴더의 ACL, 상속 플래그, 서버 측 생성 규칙에서 권한을 할당받습니다.

왜 SMB를 통해 NAS 파일은 열리는데 Docker 컨테이너에서는 열리지 않나요?

SMB 세션과 컨테이너는 서로 다른 아이덴티티를 사용합니다. 컨테이너의 실제 UID와 GID, 마운트된 경로의 숫자 소유권, 그룹 멤버십, 마운트가 읽기 전용인지 확인하세요.

NAS 공유를 복구할 때 chmod 777을 사용해야 하나요?

아니요. 모든 로컬 아이덴티티에 광범위한 접근 권한을 부여하며, ACL 상속을 손상시킬 수 있고, 잘못된 소유권이나 UID/GID 매핑 문제를 해결하지 못합니다. 의도한 사용자와 그룹을 정의한 후 소유권과 ACL을 적절히 복구하세요.

rsync가 NAS 파일 권한을 보존할 수 있나요?

선택한 옵션, 실행 권한, 두 파일 시스템이 이를 지원할 때 POSIX 권한 및 기타 메타데이터를 보존할 수 있습니다. ACL과 확장 속성은 추가 옵션이 필요합니다. -A 그리고 -X.

오래된 파일을 복구한 후에도 왜 새 파일이 계속 손상되나요?

생성 경로가 여전히 잘못되었습니다. 대상 폴더의 상속된 ACL, SMB 또는 NFS 아이덴티티, 애플리케이션 umask, Samba 생성 규칙, 컨테이너 UID/GID를 확인하세요.