외부 DAS를 ZimaOS에 연결하면 확인해야 할 감지 계층이 최소 두 가지 있습니다. Linux에서 각 블록 장치를 인식할 수 있는지, 그리고 ZimaOS Storage 인터페이스가 관리를 위해 해당 드라이브를 등록하는지입니다. 2025년 12월의 이 스레드는 이러한 구분이 중요한 이유를 보여주었습니다.
최초 게시자는 TerraMaster D4-320과 ZimaOS 1.5.3을 사용 중이었으며, 인터페이스에서 드라이브 4개 중 3개만 볼 수 있었습니다. 이후 다른 사용자들은 이와 관련되지만 다른 증상을 보고했습니다. 4개의 디스크가 모두 다음 위치에 표시되었습니다. lsblk 및 fdisk -l하지만 ZimaOS Storage 앱에는 어느 것도 올바르게 표시되지 않았습니다.
먼저 커널 감지와 ZimaOS Storage 등록을 구분하세요
초기에는 DAS 브리지가 모든 디스크를 독립적으로 노출하지 않는 것이 원인이라는 의견이 있었습니다. 그러나 이후 다른 사용자가 다음을 게시하면서 이 설명은 철회되었습니다. lsblk 5.5TB 디스크 4개가 각각 별도의 장치로 표시된 출력 결과입니다.
문제 해결 방향이 바뀌었습니다. 모든 디스크가 개별적으로 표시된다면 lsblk 또는 fdisk -lUSB 브리지가 최소한 해당 블록 장치들을 운영 체제에 노출하고 있다는 뜻이며, 남은 문제는 스토리지 관리 스택의 상위 계층에 있을 수 있습니다.
재포맷이나 초기화가 검증된 해결책이라고 단정하지 마세요
커뮤니티 답변에서는 수동으로 생성한 GPT/파일 시스템 레이아웃 때문에 ZimaOS Storage UI가 디스크를 무시했을 수 있다는 의견이 제시되었습니다. 이후 사용자들은 파일 시스템 시그니처와 파티션 테이블을 삭제해 보았습니다.
이러한 시도는 문제를 안정적으로 해결하지 못했습니다. 두 명의 참여자는 파괴적인 초기화 절차와 재부팅 후에도 Storage에 드라이브가 계속 표시되지 않는다고 보고했습니다. D5-300C 소유자 한 명도 비슷한 동작을 보고했습니다.
이러한 초기화 명령은 커뮤니티 참여자들이 제안한 것이며 원래 사례의 문제를 해결하지 못했으므로, 공식 복구 절차로 안내해서는 안 됩니다. 디스크 초기화 명령은 잘못된 장치에 적용할 경우 데이터를 영구적으로 파괴할 수 있습니다.
ZimaOS 팀이 D4-320 사례 재현을 시도함
IceWhale 팀원 777-Spider는 문제를 재현하기 위해 관련 DAS 하드웨어를 구매하고 있다고 밝혔습니다. 며칠 후 Dina는 팀이 Windows에서 포맷한 NTFS/exFAT 드라이브 4개가 장착된 TerraMaster D4-320을 테스트했으며, 테스트에서 4개 모두 ZimaOS에 표시되었다고 보고했습니다.
이 결과는 해당 스레드에서 ZimaOS와 TerraMaster D4-320 간의 전면적인 비호환성이 확인된 것이 아니라는 점에서 중요합니다. 대신 팀은 영향을 받은 사용자들에게 파일 시스템 형식과 드라이브가 어떤 방식으로 포맷되었는지에 대한 추가 정보를 요청했습니다.
스레드의 공식 진단 로그 수집
Dina는 블록 장치, 로컬 스토리지 API 및 devmon.service 진단 정보를 로그 파일에 기록합니다. 이 명령은 2025년 12월 스레드에서 가져온 것이며, 이후 ZimaOS 버전에서는 조정이 필요할 수 있습니다.
sudo -i
LOG=/DATA/disk-info.log; : > $LOG; { echo "=== lsblk ==="; lsblk; echo; echo "=== lsblk -f ==="; lsblk -f; echo; echo "=== curl http://127.0.0.1/v2/local_storage/disk ==="; curl http://127.0.0.1/v2/local_storage/disk; echo; echo "=== curl http://127.0.0.1/v2/local_storage/storages ==="; curl http://127.0.0.1/v2/local_storage/storages; echo; echo "=== journalctl -xe -u devmon.service ==="; journalctl -xe -u devmon.service; echo; } >> $LOG 2>&1 && echo "The output has been saved to $LOG"게시글에는 생성된 파일을 다음 위치에서 찾을 수 있다고 나와 있습니다. /ZimaOS-HD/disk-info.log Files에 저장한 후 지원팀과 공유했습니다. 이는 진단 정보 수집을 위한 것이며, 디스크를 복구하거나 포맷하는 명령이 아닙니다.
드라이브 누락과 RAID 5는 별개의 문제입니다
원 게시자는 RAID 5 클러스터도 생성하려고 했습니다. 스레드가 진행되는 동안 드라이브 누락 문제로 해당 작업 흐름을 제대로 평가할 수 없었습니다. 이후 커뮤니티의 wipe 시도 후에도 사용자는 RAID를 생성할 수 없었고 Files와 Storage에서 드라이브가 표시되지 않는 문제도 겪었습니다.
2025년 12월 15일 IceWhale의 답변에서는 포맷 및 RAID 생성 기능을 포함한 USB 장치 관리가 향후 지원될 예정이라고 밝혔습니다. 이 발언은 역사적인 로드맵 참고 사항으로 간주해야 하며, 현재 모든 ZimaOS 버전이 무엇을 지원하는지에 대한 증거로 보아서는 안 됩니다.
더 안전한 문제 해결 순서
- DAS에 물리적으로 설치된 디스크 수를 확인하세요.
- 각 디스크가 Linux 블록 장치 계층에 독립적으로 표시되는지 확인하세요.
- 이를 ZimaOS Storage 인터페이스에 표시되는 내용과 비교하세요.
- 파일 시스템 유형과 각 디스크가 이전에 어떤 방식으로 포맷되었는지 기록하세요.
- 커뮤니티 게시글에서 제안했다는 이유만으로 파티션 테이블을 삭제하지 마세요.
- 커널에서 디스크가 보이지만 ZimaOS Storage에 표시되지 않는다면 진단 정보를 수집하고 정확한 인클로저 모델, 파일 시스템 정보, ZimaOS 버전을 지원팀에 제공하세요.
ZimaOS 외장 DAS FAQ
TerraMaster D4-320은 ZimaOS에 드라이브를 3개만 표시하나요?
스레드는 그러한 결론을 뒷받침하지 않았습니다. 다른 사용자들은 서로 독립된 디스크 4개가 표시되는 것을 확인했습니다. lsblk, 이후 IceWhale 팀은 자체 D4-320 테스트에서 4개의 드라이브가 모두 표시되었다고 보고했습니다.
lsblk에서 모든 드라이브가 보이는데도 ZimaOS Storage에서 일부가 누락될 수 있는 이유는 무엇인가요?
커널 수준의 감지와 ZimaOS Storage 등록은 서로 다른 계층입니다. 원본 스레드에서는 커널이 드라이브를 열거했지만 UI에는 표시되지 않는 사례가 확인되었습니다.
드라이브가 표시되도록 sgdisk 또는 wipefs를 실행해야 하나요?
이 스레드만으로는 그렇지 않습니다. 이러한 데이터 삭제 제안은 커뮤니티 답변에서 나온 것이며 문제를 안정적으로 해결하지 못했습니다. 디스크 메타데이터를 삭제하기 전에 데이터를 백업하고 최신 지원 안내를 따르세요.
스레드에서 문제가 완전히 해결되었나요?
아니요. 팀은 NTFS/exFAT 디스크를 사용해 작동하는 D4-320 구성을 재현하고 영향을 받은 사용자들에게 진단 정보를 요청했지만, 해당 스레드에는 모든 경우에 적용되는 단일 근본 원인이나 해결 방법이 게시되지 않았습니다.
