タイトルにはNTFSとありますが、元の診断では異なる結果が確認されました。lsblk -fの出力から、USBパーティションは実際にはHFS+であることが分かりました。ユーザーは/DATA/usb-testに正常にマウントできましたが、それでもZimaOS Filesには表示されませんでした。その後、カーネルログに、ジャーナリングされたHFS+への書き込みアクセスはサポートされておらず、ファイルシステムが読み取り専用でマウントされたことが記録されました。
つまり、元の問題には2つの別々の問題が含まれていました。1つは、手動でマウントしたパスがZimaOS Filesによって管理ストレージとして扱われなかったこと、もう1つは、HFS+のジャーナリングファイルシステムがLinuxによって読み取り専用で公開されたことです。USBハードウェアの検出失敗ではありませんでした。
ラベルが正しいと決めつける前にファイルシステムを確認する
ユーザーはディスクがNTFSだと考えていました。次のコマンドを実行すると、
lsblk -fsdc1がhfsplusとして表示されました。記憶やケースのラベルではなく、実際のファイルシステムメタデータを常に確認してください。
ディスクはすでにマウントされていた
元の出力では、sdc1が次のようなパスにマウントされていました。
/DATA/usb-test
/var/lib/casaos_data/usb-testつまり、「Filesに表示されない」は、もはや「マウントされていない」と同じ意味ではありません。
手動マウントしたディスクが、必ずしも管理対象のZimaOSストレージ項目になるとは限らない
コミュニティの返信では、Filesは通常、シェルから手動でマウントした任意のディレクトリではなく、ZimaOSが管理するストレージの場所を表示すると説明されていました。この説明はIceWhaleスタッフによって確認されたものではないため、公式の保証ではなく、UIとストレージマネージャーの境界に関する可能性の高い説明として扱ってください。
カーネルはジャーナリングされたHFS+を明示的に読み取り専用として報告していた
重要なログには、ジャーナリングされたHFS+ファイルシステムへの書き込みアクセスはサポートされておらず、書き込みモードを強制すると危険であると記録されていました。
移行を容易にするためだけに、貴重なHFS+データに対して書き込みを強制するマウントを使用しないでください。
現在のZimaOSではHFS/HFS+が読み書き対応として掲載されている
IceWhaleの現在のフォーマット資料では、USBおよび内蔵ディスク上のHFS/HFS+が読み書き対応として掲載されています。これは、カーネルがジャーナリングされたボリュームを読み取り専用として扱った2026年4月の手動マウント事例よりも広い対応範囲です。
現在の対応ディスクフォーマット一覧を確認し、対象のドライブを破壊的な操作を避けてテストしてください。
一度だけ移行する場合は、読み取り専用で十分なことがある
HFS+からZimaOSのRAIDストレージへ古いMacのファイルをコピーすることが目的なら、書き込み対応を強制するよりも読み取り専用アクセスの方が安全な場合があります。データをNASにコピーして検証した後、別のファイルシステムで外付けドライブを再利用したい場合にのみ、再フォーマットしてください。
データを安全にコピーしてから再フォーマットする
exFATはクロスプラットフォームでの交換に便利です。Linuxネイティブの所有権や機能を重視するなら、ext4またはBtrfsの方が適しています。フォーマットすると既存のファイルシステムが消去されるため、変更する前に検証済みのコピーを保持してください。
USBドライブの表示に関するFAQ
元のドライブは本当にNTFSでしたか？
いいえ。lsblk -fではHFS+と識別されました。
USBディスクはZimaOSによって検出されましたか？
はい。ドライブとパーティションは検出され、パーティションは手動でマウントされました。
なぜ読み取り専用だったのですか？
元のカーネルログによると、ジャーナリングされたHFS+への書き込みアクセスがサポートされていなかったため、読み取り専用でマウントされました。
