핵심 결론: 이는 Syncthing이 작동할 때까지 chmod를 계속 변경해야 하는 문제가 아닐 가능성이 큽니다. 더 강력한 신호는 폴더가 Syncthing에서 직접 볼 수 있는 경로에 있을 때는 작동하지만, 심볼릭 링크를 통해 다른 물리적 드라이브로 연결되면 실패한다는 점입니다. CasaOS에서는 먼저 컨테이너의 마운트 경로를 확인한 다음 UID/GID 권한을 확인해야 합니다.
“권한을 끝까지 이미 설정했는데… /DATA/AppData/를 대상으로 하면 작동하고, 링크가 다른 물리적 드라이브를 가리키면 작동하지 않습니다.” 이 테스트 결과는 원래의 권한 오류보다 더 유용합니다. 문제를 스토리지 경로로 좁혀 주기 때문입니다.
심볼릭 링크를 가장 먼저 의심해야 하는 이유
Syncthing은 심볼릭 링크를 “대상으로 이동해 그곳에 있는 항목을 동기화하라”는 의미로 처리하지 않습니다. 문서에 설명된 Syncthing의 심볼릭 링크 동작에 따르면 심볼릭 링크는 동기화될 수 있지만 절대 따라가지는 않습니다. 또한 폴더 설정에서는 실제 장치 로컬 경로를 요구합니다. Syncthing 폴더 경로는 하드 드라이브에 있는 폴더의 물리적 경로입니다.
따라서 다음과 같은 경로는 의심해 볼 필요가 있습니다.
/DATA/Documents/Syncthing/SyncFiles → 심볼릭 링크 → /some/other/physical/drive
Syncthing이 Docker에서 실행 중이라면 호스트에서는 해당 링크를 확인할 수 있어도, 컨테이너에서는 대상 자체가 전혀 보이지 않을 수 있습니다.
CasaOS Syncthing 앱을 통해 두 번째 드라이브가 사라지는 이유를 알 수 있습니다
Syncthing의 공식 CasaOS App Store 정의는 이 점에서 특히 유용합니다. 해당 compose 파일은 두 개의 호스트 경로를 컨테이너에 바인드 마운트합니다.
/DATA/AppData/$AppID/config → /config
/DATA → /DATA
실제 볼륨 매핑은 CasaOS Syncthing compose 파일에서 확인할 수 있습니다.
즉, 호스트의 /DATA 트리 안에 물리적으로 존재하는 대상은 Syncthing 컨테이너 내부의 /DATA에서도 보여야 합니다. 하지만 심볼릭 링크가 최종적으로 해당 트리 외부의 호스트 마운트를 가리킨다면, 컨테이너에는 실제 대상에 대한 별도의 바인드 마운트가 필요합니다. Docker 바인드 마운트를 사용하면 호스트 디렉터리를 컨테이너에 명시적으로 마운트해야 합니다.
Use this test to distinguish a path problem from a permission problem
이 테스트를 사용하여 경로 문제와 권한 문제를 구분하세요
다음 순서로 점검을 실행하세요. 또다시 재귀적 chmod부터 시작하지 마세요.
1. CasaOS 호스트에서 실제 경로 확인
readlink -f "/DATA/Documents/Syncthing/SyncFiles" /DATA명령이 다음 경로 밖의 경로를 반환한다면
2. Syncthing 컨테이너에서 동일한 대상을 볼 수 있는지 확인
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"
그런 다음 컨테이너 내부에 존재해야 하는 경우 확인된 대상 경로를 테스트하세요. 호스트에서는 해당 경로를 나열할 수 있지만 컨테이너에서는 나열할 수 없다면, 아직 권한이 주된 문제가 아닙니다. 컨테이너 네임스페이스에 경로가 없는 것입니다.
3. 실제 컨테이너 마운트 검사
docker inspect syncthing
다음을 확인하세요. 마운트 섹션. 동기화하려는 드라이브의 호스트 소스와 컨테이너 대상을 확인할 수 있어야 합니다.
더 깔끔한 해결 방법은 실제 드라이브를 바인드 마운트한 다음 해당 컨테이너 경로를 사용하는 것입니다.
외부 드라이브가 다음 경로 밖에 있다면 /DATA직접 Syncthing에 노출하고 심볼릭 링크 뒤에 숨기지 마세요. 개념적으로 compose 항목은 다음과 같습니다.
볼륨:
- 유형: bind
소스: /real/host/path/to/external-drive
대상: /sync-drive
그런 다음 Syncthing 폴더 경로를 다음과 같이 명시적으로 구성하세요.
/sync-drive/Dev Files
이는 마법처럼 정해진 경로가 아니므로 compose 구성에 맞는 대상을 선택하세요. 중요한 점은 컨테이너가 실제 호스트 디렉터리를 마운트된 볼륨으로 받아야 한다는 것입니다.
업스트림 LinuxServer Syncthing 이미지는 동일한 방식을 사용하며 /path/to/data1:/data1 및 /path/to/data2:/data2와 같이 호스트와 컨테이너 간 데이터를 별도로 매핑하는 방법을 문서화합니다. 또한 해당 Syncthing PUID/PGID 매핑에서는 컨테이너의 ID가 호스트 볼륨 소유권과 일치해야 하는 이유를 설명합니다.
마운트가 올바른지 확인한 후에만 소유권과 권한을 수정하세요
원래 문제 해결 과정에는 다음과 같은 제안이 포함되어 있었습니다.
sudo chmod -R 770 /path/to/folder
770 는 일부 설정에서 적절할 수 있지만, Syncthing이 실제로 해당 디렉터리를 소유한 사용자 또는 해당 디렉터리를 소유한 그룹에 속한 사용자로 실행되는 경우에만 도움이 됩니다. CasaOS 앱은 다음을 전달합니다. PUID 및 PGID LinuxServer 자체 문서에 따르면 호스트 볼륨 소유권은 구성된 PUID/PGID와 일치해야 합니다.
사용자 이름을 추측하지 말고 ID를 확인하세요 casaos 다음 명령이면 충분합니다.
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-drive
숫자 형식의 UID/GID가 일치하지 않으면 의도적으로 소유권이나 그룹 멤버십을 변경하세요. 다음 명령은 피하세요. chmod -R 777; 이는 실제 문제를 숨기고 접근 제어를 약화합니다.
“file exists” 오류가 실제로 알려 주는 내용
메시지는 다음과 같습니다.
mkdir /DATA/Documents/Syncthing/SyncFiles: file exists
최종 경로가 그렇다는 것을 증명하지는 않습니다 개발 파일 디렉터리가 문제입니다. Syncthing은 폴더 루트를 준비하는 과정에서 실패하고 있습니다. 상위 경로가 심볼릭 링크이거나 컨테이너 내부에서 다르게 확인되면 애플리케이션이 일반 디렉터리 경로를 예상한 위치에서 파일 시스템 객체를 만날 수 있습니다.
따라서 가장 빠른 진단 방법은 동일한 디렉터리를 삭제하고 다시 만드는 것이 아닙니다. 다음 항목을 비교하세요.
- 호스트에서 확인된 실제 경로;
- 컨테이너 내부에서 보이는 경로;
- 컨테이너의 bind mount;
- 대상 소유권과 숫자 형식의 PUID/PGID를 비교하세요.
깔끔한 기준 구성을 확인하려면 CasaOS Syncthing 설정에서 여러 드라이브를 사용자 지정하기 전에 동일한 경로로 동기화하는 일반적인 흐름을 확인할 수 있습니다. 대체 백업 또는 파일 동기화 도구를 비교할 때는 ZimaOS 앱 플랫폼이 유용합니다. 심볼릭 링크로 여러 물리 드라이브를 연결하는 대신 최종적으로 여러 드라이브를 통합하려는 경우 ZimaCube 2가 스토리지 중심 하드웨어 옵션입니다.
FAQ
소유자를 root에서 casaos로 변경해서 해결해야 하나요?
그 자체로는 아닙니다. 컨테이너가 실제 대상 경로를 볼 수 있어야 소유권이 중요해집니다. 먼저 bind mount와 숫자 형식의 PUID/PGID를 확인하세요.
직접 경로는 작동하는데 다른 드라이브로 연결되는 심볼릭 링크는 실패하는 이유가 무엇인가요?
디렉터리가 컨테이너에 마운트되어 있다면 두 파일 시스템 모두에 직접 경로가 존재합니다. 심볼릭 링크는 컨테이너에 마운트되지 않은 호스트 위치로 연결될 수 있으므로 Syncthing이 해당 경로를 탐색하지 못할 수 있습니다.
Syncthing은 동기화를 위해 심볼릭 링크를 따라 대상 디렉터리로 이동하나요?
아니요. Syncthing 문서에 따르면 심볼릭 링크는 절대 따라가지 않습니다. Syncthing 프로세스에서 보이는 실제 폴더 경로를 사용하세요.
무엇을 먼저 변경해야 하나요?
심볼릭 링크를 확인하고, Syncthing 컨테이너의 마운트를 점검한 다음 실제 외장 드라이브 디렉터리를 bind mount하세요. 그런 다음 PUID/PGID와 권한을 확인하세요.
