Le fil d’origine montre pourquoi « l’application ne peut pas écrire sur le RAID » ne doit pas être immédiatement considéré comme un problème de permissions de ZimaOS. La première réponse de la communauté affirmait que les conteneurs de l’App Store disposaient normalement d’un accès en lecture seule en dehors de leur propre AppData, sauf si un dossier était créé ou « touché » via Fichiers. L’auteur du message initial a fait exactement cela, sans pouvoir pour autant créer des dossiers SFTPGo ni supprimer de la musique depuis Navidrome.
Après ces contre-exemples, l’intervenant a révisé son explication : la propriété du système de fichiers n’est qu’un niveau parmi d’autres. Chaque application possède également son propre utilisateur de conteneur, ses chemins internes attendus et ses limites fonctionnelles. Cette correction ultérieure constitue la leçon la plus fiable.
Il existe trois niveaux de permissions distincts
- Stockage hôte de ZimaOS : le véritable dossier du RAID ou du disque, ainsi que sa propriété et ses permissions.
- Mappage des volumes Docker : le dossier hôte est-il monté dans le conteneur et le montage est-il en lecture seule ?
- Comportement de l’application : avec quel utilisateur l’application s’exécute-t-elle et le logiciel prend-il lui-même en charge la création, la suppression ou le renommage de fichiers ?
Une défaillance à n’importe lequel de ces niveaux peut se manifester par une erreur « permission refusée ».
Créer le dossier dans Fichiers n’était pas une solution universelle
La suggestion initiale consistait à créer ou déplacer le dossier cible via Fichiers de ZimaOS afin que sa propriété soit correctement appliquée. L’auteur du message initial a créé srv/data sur le RAID, l’a indiqué à SFTPGo, mais a tout de même reçu des erreurs de permission refusée.
La méthode Fichiers ne peut donc pas être présentée comme une solution garantie pour toutes les applications.
SFTPGo nécessite un chemin accessible en écriture correspondant à son utilisateur d’exécution et à sa configuration
SFTPGo s’exécute avec ses propres permissions et règles de dossiers virtuels et de répertoires personnels. Un dossier hôte peut exister et être visible tout en restant inaccessible en écriture pour le processus SFTPGo.
Pour un déploiement actuel, vérifiez ensemble le dossier hôte, le mode de montage Docker, l’UID/GID du conteneur et le répertoire personnel ou dossier virtuel configuré pour l’utilisateur SFTPGo.
Navidrome est avant tout un serveur de bibliothèque multimédia
L’intervenant d’origine a indiqué que Navidrome devait être considéré comme accessible en lecture seule pour la gestion de la bibliothèque et que la suppression de pistes depuis Navidrome n’était pas prise en charge dans son contexte. L’impossibilité de l’utilisateur à supprimer une chanson ne constituait donc pas une preuve suffisante que les permissions du RAID étaient globalement défaillantes.
Gérez les fichiers musicaux sources avec Fichiers ou un autre outil de gestion de fichiers, sauf si la version actuelle précise de Navidrome documente une fonction prise en charge de modification des fichiers.
Vérifiez si le volume Docker est monté en lecture seule
Un mappage de volume peut explicitement utiliser le mode lecture seule. Si l’application est censée modifier des fichiers, le dossier hôte doit être mappé en lecture-écriture et l’identité du processus doit disposer des permissions d’écriture sur le système de fichiers hôte.
Les versions actuelles de ZimaOS permettent d’inspecter et de modifier les mappages de volumes des applications depuis les paramètres de l’application.
Les versions actuelles de ZimaOS rendent les chemins hôte et conteneur plus visibles
IceWhale documente désormais la relation entre les chemins utilisés par l’application, tels que /config ou /media, et les véritables dossiers de stockage qui les sous-tendent.
Consultez le modèle actuel des chemins d’application de ZimaOS avant d’utiliser chmod/chown récursif comme première mesure.
N’utilisez pas chmod 777 comme raccourci de diagnostic
Des permissions d’écriture trop larges peuvent masquer le véritable problème et exposer des données partagées à des processus sans rapport. Elles ne corrigent pas non plus une application qui ouvre volontairement un volume en lecture seule ou qui refuse un chemin en raison de sa propre configuration.
Modifiez uniquement la propriété ou les permissions de groupe minimales requises par l’application.
Une meilleure séquence de diagnostic
- Confirmez le dossier hôte exact dans ZimaOS.
- Confirmez que le volume de l’application mappe ce dossier vers le chemin de conteneur attendu.
- Vérifiez si le mappage est en lecture seule.
- Identifiez l’UID/GID ou l’utilisateur avec lequel le conteneur s’exécute.
- Vérifiez que cette identité peut écrire dans le dossier hôte.
- Confirmez que l’application elle-même prend en charge l’opération tentée.
FAQ sur les permissions du stockage des applications
La recréation du dossier dans Fichiers de ZimaOS a-t-elle résolu le problème SFTPGo d’origine ?
Non. L’auteur du message initial a essayé cette méthode et a tout de même reçu une erreur de permission refusée.
Un dossier du RAID accessible en lecture devient-il automatiquement accessible en écriture dans toutes les applications ?
Non. Le mode de montage Docker, l’UID/GID du conteneur et le comportement de l’application restent déterminants.
Navidrome doit-il être utilisé comme gestionnaire de fichiers généraliste ?
Non. Gérez la source musicale en dehors de Navidrome, sauf si l’application actuelle prend explicitement en charge la modification des fichiers.
