En résumé : ne « corrigez » pas les points de montage racine de ZimaOS avec chmod 777
Dans la version 1.6.2 Beta 2, les volumes Btrfs nouvellement montés apparaissaient comme root:root avec les permissions 755, si bien qu’un utilisateur SSH standard ne pouvait plus écrire directement à la racine de /media/<volume>. Il s’agissait d’une observation réelle concernant la bêta. Cela ne signifie pas automatiquement que la version actuelle est défectueuse, et assouplir récursivement les permissions de la racine d’un point de montage constitue une solution de contournement risquée.
La bêta a modifié plusieurs aspects de la sécurité du stockage
Un rapport connexe sur la version 1.6.2 Beta 2 indiquait que la migration des données d’application était bloquée par une nouvelle politique de sécurité, et IceWhale a reconnu que cet échec de migration précis était un problème connu qui devait être corrigé. La version stable 1.6.2 a ensuite intégré un renforcement plus large de la sécurité ainsi que des correctifs liés au stockage. La période bêta comportait donc clairement à la fois des changements de sécurité intentionnels et au moins une régression.
Le résumé des changements de ZimaOS 1.6.x fournit un contexte historique utile.
La documentation publique actuelle ne garantit pas un accès en écriture sans privilèges root à la racine de chaque point de montage
ZimaOS traite désormais le stockage comme un service géré utilisé par Fichiers, les partages SMB et les chemins Docker. Le flux de travail pris en charge consiste à créer des dossiers ou des partages et à associer les applications au chemin approprié, plutôt qu’à compter sur des écritures arbitraires depuis le shell à la racine de chaque disque monté.
Le guide de stockage actuel de ZimaOS et le guide ZimaOS sur les chemins d’application et la migration constituent de meilleures références actuelles que le seul mode du système de fichiers de la bêta.
Si un script doit disposer d’un accès en écriture, accordez-lui un dossier dédié
sudo mkdir -p /media/YourVolume/automation
sudo chown YOUR_USER:YOUR_GROUP /media/YourVolume/automation
sudo chmod 775 /media/YourVolume/automationCiblez le dossier dont le script a réellement besoin. Ne modifiez pas récursivement la racine entière du disque. Le manuel de chmod et le manuel de chown sont les références fournies en amont.
Comment distinguer une politique d’une régression
Si Fichiers, SMB et l’accès aux applications fonctionnent, mais que les écritures directes depuis le shell à la racine du volume échouent, cela peut être compatible avec un modèle de permissions gérées. Si l’interface de migration des données ou des partages prise en charge est bloquée, relevez l’erreur exacte et la version utilisée ; il s’agit d’un autre type de problème, qui doit être testé avec la version stable actuelle.
