L’objectif initial de cette discussion de novembre 2025 était simple : conserver ZimaOS et les applications sur le SSD interne de 512 Go du mini-PC, tout en utilisant un disque dur USB externe Seagate de 5 To pour les médias et les téléchargements. La difficulté venait du fait que le disque externe était traité comme un montage Linux générique avant de comprendre comment ZimaOS gère déjà le stockage.
L’utilisateur a expérimenté un montage manuel sous /var, puis le serveur a planté et ZimaOS a été réinstallé. Ensuite, le disque a été monté sous un chemin de données ZimaOS et mappé dans SABnzbd, mais l’application renvoyait toujours une erreur d’autorisation. Cette discussion contient donc deux enseignements distincts : choisir d’abord un chemin hôte géré et sûr, puis résoudre séparément les permissions du conteneur.
N’utilisez pas /var comme point de montage USB arbitraire
ZimaOS est un système d’exploitation de type appliance avec des chemins système gérés. L’utilisateur à l’origine de la question a indiqué avoir monté le disque externe sous /var semblait fonctionner au début, mais a été suivi d’un plantage complet du serveur et d’une réinstallation.
La discussion ne prouve pas que le montage lui-même a directement provoqué le plantage, mais elle suffit à déconseiller d’utiliser des répertoires système comme emplacements de stockage ordinaires pour les disques multimédias.
Laissez ZimaOS gérer le disque externe
La version actuelle de ZimaOS prend en charge le stockage USB bien plus largement que l’environnement de 2025 présenté dans cette discussion. Un disque USB peut être ajouté via Paramètres > Stockage, puis utilisé comme stockage ordinaire plutôt que d’être monté manuellement sur un point de montage Linux créé de toutes pièces.
Pour un nouveau déploiement, commencez par le processus actuel de ZimaOS pour ajouter un stockage USB. Une fois le disque géré, utilisez son véritable dossier de stockage dans le mappage des volumes de l’application.
Le disque source est finalement apparu sous les chemins gérés par ZimaOS
Le chemin exact affiché sur une installation de 2025 ne doit pas être copié sur un autre serveur. Les noms de périphériques tels que sda, sdb, et sdc peut changer selon l’ordre de démarrage et le matériel connecté.
Mappez un dossier, pas le périphérique bloc brut
Les applications Docker doivent normalement recevoir un répertoire tel qu’un dossier de téléchargements ou de médias, et non le périphérique brut. /dev/sda1. ZimaOS monte le système de fichiers ; le conteneur reçoit un dossier hôte provenant de ce système de fichiers monté.
L’explication actuelle de la façon dont le stockage hôte devient un volume de conteneur aide à éviter de confondre le périphérique de disque, le point de montage et le chemin du conteneur.
Un montage correct peut tout de même générer une erreur d’autorisation
L’utilisateur source a atteint /DATA/HDD1 et l’a mappé dans SABnzbd, mais l’application ne pouvait pas utiliser le répertoire de téléchargement sélectionné. Cela signifie que la visibilité du stockage n’était plus le seul problème.
Les processus Docker s’exécutent avec un utilisateur ou un groupe à l’intérieur du conteneur. Si le dossier hôte appartient à un autre utilisateur et possède des autorisations restrictives, le conteneur peut voir le chemin tout en étant incapable de créer des fichiers.
Ne copiez pas PUID 999 aveuglément
Une réponse de la communauté conseillait à l’utilisateur de remplacer PUID 1000 par 999. Cela correspondait peut-être au modèle de comptes de ZimaOS utilisé par la personne ayant répondu, mais ce n’est pas une constante universelle.
Avant de modifier PUID ou PGID, identifiez le propriétaire du dossier hôte réel et l’utilisateur sous lequel l’application est censée s’exécuter. Une valeur numérique qui fonctionne sur une installation peut désigner un autre compte sur une autre installation.
Les commandes chmod et chown récursives sont puissantes et destructrices
Une réponse ultérieure de la communauté a suggéré d’utiliser récursivement chmod 775 et chown sur le chemin de téléchargement. Ces commandes peuvent être utiles pour l’administration Linux, mais elles modifient chaque fichier et répertoire situé sous la cible. Elles n’ont pas été publiées par le personnel d’IceWhale dans ce fil.
Avant de modifier récursivement le propriétaire :
- confirmez le chemin cible exact ;
- vérifiez que le système de fichiers prend en charge la propriété Linux standard ;
- comprenez quels utilisateurs ou services utilisent déjà le dossier ;
- sauvegardez les métadonnées ou les autorisations importantes si le dossier est partagé par plusieurs applications.
Le type de système de fichiers peut modifier le modèle d’autorisations
Un disque ext4 stocke directement les UID, GID et bits de mode Linux. exFAT et certaines configurations NTFS peuvent plutôt gérer la propriété via des options de montage. Si les changements de PUID n’ont aucun effet, vérifiez le système de fichiers avant de modifier à répétition les paramètres de l’application.
Une organisation plus propre pour les applications multimédias
Une configuration pratique consiste à organiser ainsi :
- SSD interne : système ZimaOS et petit environnement d’exécution des applications ;
- grand disque dur externe : médias, téléchargements, sauvegardes et autres données volumineuses ;
- AppData persistant : placé sur un emplacement de stockage offrant une capacité suffisante et une couverture de sauvegarde ;
- pour chaque application : des mappages de volumes explicites vers les seuls dossiers dont elle a besoin.
Cela empêche un téléchargement multimédia de remplir le disque système et facilite la sauvegarde séparée de la configuration de l’application et des fichiers multimédias volumineux.
FAQ sur les disques durs externes sous ZimaOS
Dois-je monter manuellement un disque dur externe sous /var ?
Non, pour une utilisation normale de ZimaOS actuellement. Utilisez l’interface Stockage et les chemins de stockage gérés.
SABnzbd doit-il mapper directement /dev/sda1 ?
Non. Mappez un répertoire hôte normal du système de fichiers monté vers le chemin de téléchargement attendu par le conteneur.
Pourquoi l’application voit-elle le dossier, mais ne parvient-elle pas à y écrire ?
Les autorisations du système de fichiers hôte, le propriétaire, ou le PUID/PGID du conteneur peuvent ne pas autoriser les écritures.
PUID 999 est-il une valeur standard de ZimaOS ?
Non. Il s’agissait d’une suggestion spécifique à la communauté et elle doit être vérifiée sur le système réel.
