Lorsque chown et chmod semblent ne rien faire sur une clé USB, commencez par identifier le système de fichiers. La réponse de la communauté évoquait NTFS ou exFAT, ce qui est une explication plausible, car ces systèmes de fichiers ne se comportent pas comme ext4/Btrfs avec une gestion native des propriétaires Unix et des bits de mode.
La source ne précise pas quel système de fichiers MikeFrizz utilisait, et l’auteur du message d’origine n’est jamais revenu confirmer le résultat. Il faut donc conserver cette approche de dépannage tenant compte du système de fichiers, plutôt que d’affirmer que toutes les clés USB sous ZimaOS ignorent les permissions.
Identifiez le système de fichiers USB avant de modifier les permissions
Vérifiez le format du disque dans le stockage de ZimaOS ou à l’aide d’une commande en lecture seule telle que :
lsblk -fLes versions actuelles de ZimaOS prennent en charge l’accès en lecture/écriture à NTFS, exFAT, ext4 et Btrfs, entre autres formats. Toutefois, la « prise en charge en lecture/écriture » ne signifie pas que tous les systèmes de fichiers conservent les métadonnées Unix UID/GID/mode de la même manière.
Consultez la matrice actuelle des systèmes de fichiers pris en charge.
NTFS et exFAT présentent souvent les permissions via les options de montage
Sous Linux, exFAT et de nombreuses configurations de montage NTFS présentent les fichiers avec des valeurs de propriétaire et de mode dérivées des options de montage, au lieu d’enregistrer les modifications de permissions POSIX ordinaires exactement comme ext4. Par conséquent, chown ou chmod peuvent sembler inefficaces ou leurs modifications peuvent disparaître après un nouveau montage.
Cela ne signifie pas que le disque est en lecture seule ou qu’il est défectueux.
Un système de fichiers Linux offre à Docker les permissions POSIX les plus prévisibles
Si le disque USB est exclusivement destiné à ZimaOS/Linux et que vous avez besoin d’un contrôle réel des UID/GID et des modes, ext4 ou Btrfs constitue un choix plus naturel. Le reformatage est destructif : copiez donc les données ailleurs avant de changer de système de fichiers.
Évitez d’utiliser un lien symbolique hôte comme méthode principale de migration du stockage Docker
L’utilisateur source a copié les données d’Immich sur une clé USB et créé un lien symbolique depuis l’ancien emplacement. Les conteneurs ne suivent pas automatiquement les liens symboliques de l’hôte vers des chemins situés en dehors de leur espace de noms de volumes montés. Le lien symbolique peut pointer vers un chemin que le conteneur ne peut pas voir.
Un montage bind ou un volume direct est plus clair et plus facile à vérifier.
Montez directement le dossier USB dans Immich
Au lieu de conserver un ancien chemin hôte et de le rediriger avec un lien symbolique, modifiez le volume de l’application ou du conteneur Immich afin que le véritable dossier USB soit monté sur le chemin du conteneur attendu par Immich.
La documentation actuelle d’IceWhale explique que le chemin hôte peut être modifié sans changer le chemin côté conteneur.
Consultez le modèle actuel des chemins de volumes Docker de ZimaOS.
Ne déplacez pas aveuglément tous les composants d’Immich vers un stockage USB arbitraire
Les bibliothèques multimédias et le stockage des téléversements d’Immich n’ont pas les mêmes exigences que la base de données PostgreSQL et l’état de l’application. Avant de déplacer des répertoires, identifiez précisément le volume hôte concerné et suivez les instructions actuelles de déploiement et de migration d’Immich.
Ne déplacez pas le répertoire d’une base de données active à l’aide d’un lien symbolique lorsque les conteneurs sont en cours d’exécution.
Corrigez le mappage avant d’utiliser largement chmod 777
Si le conteneur ne peut pas voir le bon dossier hôte, modifier les permissions ne corrigera pas le chemin. Vérifiez d’abord le montage, puis accordez uniquement l’accès minimal requis au conteneur pour l’utilisateur ou le groupe concerné.
FAQ sur les permissions USB
ZimaOS prend-il en charge la lecture/écriture sur NTFS et exFAT ?
Oui, la documentation actuelle d’IceWhale indique que les deux sont pris en charge en lecture/écriture.
Pourquoi chmod/chown peuvent-ils malgré tout se comporter différemment ?
Ces systèmes de fichiers n’utilisent pas les sémantiques natives Linux POSIX des propriétaires et des modes de la même manière qu’ext4 ou Btrfs.
Le système de fichiers de l’utilisateur source et la solution finale ont-ils été confirmés ?
Non. Le système de fichiers a été déduit par une réponse de la communauté et l’auteur du message d’origine n’a pas communiqué le résultat.
