L’utilisateur source de mars 2026 construisait un premier NAS à partir d’un client léger HP T640 équipé d’un disque système NVMe de 128 Go et de trois disques durs connectés en USB. Son plan était pertinent : conserver les photos sur un disque externe, les sauvegarder sur un second disque et placer les médias Plex sur un disque séparé de 4 To. Le principal problème n’était pas l’impossibilité d’utiliser le stockage USB. Immich s’est arrêté parce que les mappages de volumes de l’application avaient été modifiés incorrectement.
La partie de la discussion consacrée aux capacités de stockage doit également tenir compte d’une limite temporelle. En mars 2026, l’utilisateur et le répondant considéraient les disques USB comme plus limités que le stockage interne. La documentation actuelle de ZimaOS indique désormais explicitement que les disques USB suivent la même logique que les disques durs et SSD internes et peuvent être utilisés pour le stockage, ajoutés à une matrice ou utilisés pour étendre l’espace existant.
Le NAS source dépendait entièrement du stockage USB
La configuration comprenait :
- client léger HP T640 équipé d’un AMD R1505G, de 8 Go de RAM et d’un SSD NVMe de 128 Go ;
- deux disques durs Seagate de 2,5 pouces dans des boîtiers USB distincts ;
- un disque dur externe WD de 4 To pour les médias Plex.
Comme le client léger ne disposait pas de baies internes pratiques, l’utilisateur avait besoin que le stockage USB se comporte comme un stockage NAS principal plutôt que comme un support amovible temporaire.
Les disques sont apparus comme stockage USB
L’utilisateur pensait que les disques externes ne pouvaient pas être traités comme du stockage interne ni utilisés pour le RAID. Cela correspondait au comportement et aux attentes liés à sa configuration de mars 2026, et non au modèle de stockage actuel de ZimaOS.
Le ZimaOS actuel traite les clés USB comme un stockage normal
La documentation actuelle d’IceWhale indique que les disques USB suivent la même logique que les disques durs et SSD internes : ils peuvent être utilisés comme stockage individuel, ajoutés à une matrice ou utilisés pour étendre l’espace existant.
Utilisez le workflow de stockage actuel de ZimaOS pour les clés USB au lieu de bâtir un nouveau système sur l’ancienne idée selon laquelle le RAID USB ne serait catégoriquement pas pris en charge.
L’échec d’Immich était dû à une erreur de mappage fichier-répertoire
L’utilisateur source a modifié les paramètres de volume d’Immich, et Docker a renvoyé une erreur indiquant qu’il ne pouvait pas monter :
/media/Photos/Immich
→ /etc/localtime/etc/localtime dans le conteneur est un fichier, et non un répertoire de photothèque. Docker a donc rejeté la tentative de monter un dossier par-dessus ce fichier.
/etc/localtime mappage de fichier.Conservez le stockage des photos et /etc/localtime dans des montages distincts
L’intervenant de la communauté a correctement séparé les deux rôles :
- dossier de photos sur l’hôte → répertoire de téléversement/de données d’Immich ;
- hôte
/etc/localtimefichier → conteneur/etc/localtimefichier.
Les règles actuelles des montages bind Docker exigent toujours que les types de la source et de la destination correspondent. Un répertoire ne peut pas être monté sur un fichier comme s’ils étaient interchangeables.
La solution de contournement par montage bind de /DATA était une suggestion historique de la communauté
L’intervenant a également suggéré de créer un répertoire stable sous /DATA et y monter le chemin USB, car les disques externes pourraient ne pas être prêts lorsque les applications démarrent après un redémarrage.
Il s’agissait d’une recommandation de la communauté pour la version mentionnée dans la source. La version actuelle de ZimaOS offre une meilleure prise en charge du stockage USB géré ; une nouvelle installation doit donc d’abord utiliser l’interface Stockage et le sélecteur de volumes gérés de l’application, plutôt que de créer un montage bind personnalisé au démarrage.
Dirigez Immich vers le stockage géré, pas vers un chemin d’appareil brut
La version actuelle de ZimaOS recommande de placer les données des applications et les grandes bibliothèques multimédias sur l’espace de stockage prévu à cet effet, plutôt que de remplir le disque système. Utilisez le chemin hôte sélectionné par ZimaOS, puis conservez le chemin côté conteneur attendu par Immich.
Pour les mappages d’applications actuels, le modèle de chemins de stockage des applications de ZimaOS explique comment les chemins de l’hôte et du conteneur s’articulent.
Le RAID et la sauvegarde répondent toujours à des problèmes différents
Même si la version actuelle de ZimaOS peut utiliser des disques USB dans des baies, le RAID 1 ne remplace pas une seconde sauvegarde indépendante. Deux disques USB dans une même baie protègent contre la défaillance d’un disque membre, mais pas contre une suppression accidentelle, un logiciel malveillant, des problèmes de boîtier ou de contrôleur, ni la perte de l’ensemble du NAS.
L’idée de l’utilisateur source de conserver une copie supplémentaire reste utile, même si les fonctionnalités de stockage ont évolué.
Les médias Plex sont plus simples que les données d’état de l’application Immich
L’utilisateur considérait le disque Plex de 4 To comme remplaçable, car le contenu vidéo pouvait être récupéré. Il s’agit d’une distinction de risque raisonnable : les fichiers multimédias, les photos Immich, les données de la base Immich et la configuration de l’application ne nécessitent pas forcément le même niveau de redondance ou la même stratégie de sauvegarde.
FAQ sur le stockage USB externe
La version actuelle de ZimaOS peut-elle utiliser des disques USB comme stockage géré ?
Oui. La documentation actuelle du stockage prend explicitement en charge les disques USB comme supports de stockage et membres de baies.
Pourquoi Immich a-t-il cessé de fonctionner après la modification du répertoire ?
Le dossier de photos a été accidentellement mappé sur le /etc/localtime chemin de fichier.
Les utilisateurs actuels doivent-ils créer des montages bind manuels de /DATA pour chaque disque USB ?
Non. Il s’agissait d’une solution de contournement historique proposée par la communauté. Commencez par utiliser les contrôles actuels du stockage géré et des volumes d’application.
