Le titre indique NTFS, mais le diagnostic source a révélé autre chose. lsblk -f a montré que la partition USB était en réalité en HFS+. L’utilisateur a réussi à la monter sous /DATA/usb-test, mais elle n’apparaissait toujours pas dans Fichiers de ZimaOS. Le noyau a ensuite indiqué que l’accès en écriture à un système de fichiers HFS+ journalisé n’était pas pris en charge et que le système de fichiers avait été monté en lecture seule.
La source contient donc deux problèmes distincts : un chemin monté manuellement que Fichiers de ZimaOS ne considérait pas comme un stockage géré, et un système de fichiers HFS+ journalisé que Linux exposait en lecture seule. Il ne s’agissait pas d’un échec de détection matérielle USB.
Vérifiez le système de fichiers avant de supposer que l’étiquette est correcte
L’utilisateur pensait que le disque était en NTFS. La commande :
lsblk -fa indiqué que sdc1 était en hfsplus. Fiez-vous toujours aux métadonnées réelles du système de fichiers plutôt qu’à vos souvenirs ou à l’étiquette du boîtier.
Le disque était déjà monté
La sortie source indiquait que sdc1 était monté sous des chemins comprenant :
/DATA/usb-test
/var/lib/casaos_data/usb-testCela signifie que « non visible dans Fichiers » ne voulait plus dire « non monté ».
Un montage manuel ne constitue pas nécessairement une entrée de stockage gérée par ZimaOS
La réponse de la communauté avançait que Fichiers affiche généralement les emplacements de stockage gérés par ZimaOS plutôt que les répertoires arbitraires créés par un montage manuel depuis le shell. Cette explication n’a pas été confirmée par l’équipe d’IceWhale ; considérez-la donc comme une limite probable entre l’interface et le gestionnaire de stockage, et non comme une garantie officielle.
Le noyau a explicitement signalé que le HFS+ journalisé était en lecture seule
La ligne de journal clé indiquait que l’accès en écriture à un système de fichiers HFS+ journalisé n’était pas pris en charge et que forcer le mode écriture comporterait des risques.
N’utilisez pas un montage en écriture forcée sur des données HFS+ importantes simplement pour faciliter une migration.
Les versions actuelles de ZimaOS indiquent que HFS/HFS+ est pris en charge en lecture/écriture
La documentation actuelle d’IceWhale sur les formats indique que HFS/HFS+ est pris en charge en lecture/écriture sur les disques USB et internes. Cette information est plus générale que le cas précis de montage manuel d’avril 2026, dans lequel le noyau avait traité le volume journalisé comme étant en lecture seule.
Consultez la matrice actuelle des formats de disque pris en charge, puis testez le disque concerné sans opération destructive.
Pour une migration ponctuelle, le mode lecture seule peut suffire
Si l’objectif est de copier d’anciens fichiers Mac depuis un volume HFS+ vers le stockage RAID de ZimaOS, l’accès en lecture seule est souvent plus sûr que de forcer la prise en charge de l’écriture. Copiez les données vers le NAS, vérifiez-les, puis reformatez le disque externe uniquement si vous souhaitez le réutiliser avec un autre système de fichiers.
Ne reformatez qu’après avoir copié les données en toute sécurité
exFAT est pratique pour les échanges entre plateformes ; ext4 ou Btrfs convient mieux à la gestion et aux fonctionnalités natives de Linux. Le formatage détruit le système de fichiers existant : conservez donc des copies vérifiées avant de le modifier.
FAQ sur la visibilité des disques USB
Le disque source était-il réellement en NTFS ?
Non. lsblk -f l’a identifié comme étant en HFS+.
Le disque USB a-t-il été détecté par ZimaOS ?
Oui. Le disque et la partition ont été détectés, puis la partition a été montée manuellement.
Pourquoi était-il en lecture seule ?
Le journal du noyau source indiquait que l’accès en écriture au HFS+ journalisé n’était pas pris en charge et qu’il avait été monté en lecture seule.
