원문 사용자는 휴대폰 사진 동기화에 Syncthing을 사용하고 있었지만, 파일이 저장 디스크가 아닌 시스템 드라이브에 계속 저장되었습니다. Files 앱에서 경로를 복사해 Syncthing에 직접 붙여 넣자, Syncthing은 컨테이너 자체의 파일 시스템 안에 같은 모양의 디렉터리 트리를 다시 만들었습니다.
결국 해결책은 특정 마법의 파일 시스템 명령이 아니라 개념적인 것이었습니다. Docker에는 호스트 경로와 컨테이너 경로가 있습니다. Syncthing은 CasaOS 또는 ZimaOS에서 보이는 원시 경로가 아니라 컨테이너 내부에서 보이는 경로를 사용해야 합니다.
외부 경로가 잘못된 위치에 다시 생성된 이유
Syncthing에 실제로 볼 수 없는 경로를 사용하도록 지정하면, 자체 쓰기 가능한 파일 시스템이나 매핑된 설정 위치 안에 해당 경로를 만들 수 있습니다. 원문 사용자는 폴더 이름을 외부 디스크 경로로 해석했지만, 컨테이너는 이를 자체 파일 시스템을 기준으로 한 상대 경로로 해석했습니다.
실제 호스트 마운트 지점 찾기
커뮤니티에서는 다음을 사용했습니다 lsblk 운영 체제가 외부 드라이브를 마운트한 위치를 확인하기 위해 사용했습니다. 응답자의 예시에서는 드라이브가 다음과 비슷한 경로에 표시되었습니다. /media/devmon/...원 게시자의 드라이브는 이후 /mnt/Storage1 및 /mnt/Storage2.
이러한 정확한 과거 마운트 경로는 CasaOS/ZimaBlade 예시이므로 현재의 모든 ZimaOS 경로에 일반적으로 적용되는 것으로 간주해서는 안 됩니다.
호스트 드라이브를 Syncthing에 매핑
응답자는 다음을 사용했습니다 /DATA Syncthing 측 경로로 사용합니다. 이 매핑이 설정되면 Syncthing은 그 아래의 폴더를 참조해야 합니다. /DATA 원래 호스트 마운트 경로가 아니라
사용자는 처음에 Syncthing 내부에 호스트 경로를 입력했습니다
그 후 Syncthing은 해당 내부 경로가 매핑된 볼륨을 가리키지 않았기 때문에 경로 또는 권한 오류를 반환했습니다.
최종적으로 작동한 경로는 /DATA/Documents였습니다
응답자는 호스트 드라이브를 /DATA를 Syncthing에서 사용해야 합니다.
/DATA/Documents또는 이에 해당하는 경로 ~/Documents Syncthing의 홈 경로가 매핑된 데이터 위치를 가리킬 때 사용하는 축약 표현입니다.
원 게시자는 다음 날 다시 방문해 성공했다고 확인했습니다.
재귀적 chown은 커뮤니티 작업 방식의 일부였으며, 핵심 해결책은 아니었습니다
이 스레드에서는 재귀적 chown 외부 드라이브에서. Linux가 소유한 파일 시스템에서는 적절할 수 있지만, 대상 전체의 소유권을 변경하며 IceWhale이 작성한 요구 사항은 아니었습니다.
기존 공유 디스크에서 어떤 사용자가 이미 해당 권한에 의존하는지 알기 전에는 재귀적으로 소유권을 변경하지 마세요.
현재 ZimaOS에서는 앱 저장소 매핑이 더 간편합니다
현재 ZimaOS는 애플리케이션 설정에서 호스트와 컨테이너 간 경로를 직접 문서화하며, 애플리케이션이 시스템 드라이브를 가득 채우지 않도록 앱 데이터를 관리형 저장소에 설정할 것을 권장합니다.
기존 CasaOS 마운트 위치에 의존하지 말고 현재 ZimaOS 앱 경로 모델을 Docker 볼륨에 사용하세요.
원 질문자가 Syncthing을 재설치하고 매핑을 다시 구성했습니다
첫 번째 시도들이 계속 혼란스러운 상태로 남자, 원 질문자는 Syncthing을 새로 설치하고 스토리지 드라이브를 다시 추가한 다음 다음 경로를 매핑했습니다. /mnt/Storage1 호스트의 경로를 /DATA 컨테이너 내부. 이 깔끔한 재테스트에서는 기존 컨테이너 설정을 진단에서 제외했습니다.
호스트 권한만으로는 잘못된 컨테이너 경로가 작동하지 않았습니다
사용자는 스토리지 드라이브에 SSH로 접속해 디렉터리를 만들 수 있었지만, Syncthing에 다음 경로를 사용하도록 했을 때는 여전히 실패했습니다. /mnt/Storage1/Documents 호스트에서 내부적으로. 이 부정적인 결과는 중요합니다. 호스트 사용자로 쓸 수 있다고 해서 컨테이너가 동일한 네임스페이스를 볼 수 있다는 의미는 아닙니다.
권한을 조정하기 전에 컨테이너에서 경로가 올바르게 표시되어야 합니다.
현재 ZimaOS에서는 관리형 저장소 경로를 우선 사용해야 합니다
이 글은 CasaOS 방식의 저장소 경로가 적용된 상태로 출시된 ZimaBlade에서 작성되었습니다. 현재 ZimaOS는 관리형 저장소 동작이 다르고 애플리케이션 볼륨 인터페이스도 더 명확합니다. 현재 서버에서는 경로를 임의로 가정하지 말고 ZimaOS에서 선택한 저장소 경로를 사용하세요. /mnt/Storage1 또는 /media/devmon 존재하게 됩니다.
앱에 실제로 필요한 권한만 변경하세요
Syncthing에는 일반적으로 동기화 폴더에 대한 읽기 및 쓰기 권한이 필요합니다. 매핑된 폴더가 보이지만 쓰기 권한이 없다면 해당 폴더의 소유권과 그룹 권한을 확인하세요. 여러 용도로 사용하는 드라이브 전체에 재귀적으로 소유권을 변경하기 전에, 해당 드라이브를 사용하는 다른 모든 서비스에 미칠 영향을 고려하세요.
Syncthing 외장 HDD FAQ
Syncthing은 왜 외장 드라이브 경로를 시스템 디스크 안에 만들었나요?
호스트 경로는 Syncthing이 컨테이너 내부에서 볼 수 있는 경로가 아니었습니다.
드라이브를 /DATA에 매핑한 후 작동한 경로는 무엇이었나요?
원 질문자가 확인했습니다 /DATA/Documents 작동했습니다.
재귀적 chown이 유일한 해결 방법이었나요?
아니요. 결정적인 이해는 호스트 경로와 컨테이너 경로의 차이였습니다.
