Si un nouveau membre ZimaOS reçoit les droits Lecture et écriture dans l’interface de partage, mais obtient toujours un message « permission denied », n’exécutez pas immédiatement de commandes récursives de modification de propriété sur l’ensemble du pool de stockage. La discussion source de mars 2026 a testé plusieurs hypothèses concernant la propriété, effectué une réinitialisation complète, mais n’a toujours pas établi de cause racine confirmée.
La méthode de dépannage la plus fiable consiste à séparer la couche d’autorisations ZimaOS/Samba de la couche de propriété Linux sous-jacente. Reproduisez d’abord le problème sur un petit nouveau dossier, comparez l’accès de l’administrateur et celui du membre, puis examinez uniquement le chemin exact concerné sur l’hôte.
Les autorisations du membre semblaient correctes dans l’interface
Le compte administrateur pouvait accéder aux données, tandis qu’un compte nouvellement créé nommé Andres s’était vu attribuer un accès en lecture/écriture, mais recevait une erreur d’autorisation en ouvrant les fichiers.
ZimaOS prend actuellement en charge les autorisations Samba par utilisateur
La documentation actuelle de ZimaOS distingue l’accès des membres de l’accès invité et permet à un gestionnaire d’accorder les droits Lecture ou Lecture et écriture à un partage Samba. Un membre disposant des droits Lecture et écriture devrait pouvoir télécharger, importer, renommer et supprimer des fichiers dans le partage, sous réserve que le système de fichiers sous-jacent soit accessible.
La configuration Samba multi-utilisateur actuelle de ZimaOS constitue la bonne base avant d’utiliser des correctifs au niveau du shell copiés depuis une ancienne discussion.
Reproduire le problème sur un tout nouveau dossier de test
Créez un petit dossier de test via l’interface Fichiers actuelle sur le disque de données prévu. Partagez uniquement ce dossier avec le nouveau membre en lui accordant les droits Lecture et écriture, puis connectez-vous depuis le client du membre avec ses identifiants.
Si le dossier de test fonctionne, mais que les répertoires migrés ou plus anciens échouent, le problème est probablement lié à ces chemins ou à leur propriétaire. Si le tout nouveau dossier créé dans l’interface échoue également, le problème est plus général et doit être considéré comme un éventuel problème de compte, de Samba ou d’autorisations ZimaOS, plutôt que comme un problème de propriété de fichiers héritée.
Utiliser la propriété Linux comme indicateur de diagnostic, pas comme correction appliquée à l’aveugle
Le fil a examiné les identifiants utilisateur et la propriété des répertoires, et a trouvé des chemins sous /DATA/.media appartenant à des utilisateurs et groupes Linux différents. Cela rendait plausible une incohérence de propriété pour les données migrées.
Une commande récursive suggérée chown L’opération a ensuite produit de nombreuses erreurs « Operation not permitted » dans les données gérées par les applications. Cela met en garde contre l’application d’une seule commande de modification de propriété à de vastes arborescences système ou AppData. Modifier récursivement la propriété peut interrompre les conteneurs ou les services qui attendent des UID et des GID spécifiques.
Utilisez id, ls -ld, ainsi qu’un petit fichier de test pour comprendre le chemin exact qui échoue. Ne modifiez pas les répertoires d’applications sans rapport.
La réinitialisation d’usine n’est pas une solution confirmée
Après le reformatage et la réinstallation, l’auteur a continué à signaler des erreurs d’autorisation pour le membre. Ce résultat est important : ne recommandez pas une réinitialisation destructive comme solution normale à un problème d’accès utilisateur.
Éléments à recueillir avant de signaler le problème
Si un nouveau dossier créé avec le ZimaOS actuel présente toujours le problème pour un membre nouvellement créé, notez la version de ZimaOS, le chemin du partage, le paramètre d’autorisation du membre, le système d’exploitation client, le message d’erreur exact et indiquez si l’accès administrateur fonctionne. Notez également la sortie de id pour le compte concerné et ls -ld uniquement pour le chemin concerné.
Ces éléments sont plus utiles qu’une nouvelle modification générale de la propriété. Le fil source s’est terminé avec une communauté considérant la reproduction après une installation propre comme inattendue et méritant une investigation plus approfondie, et non par une correction vérifiée en une ligne.
