Pourquoi les permissions des fichiers sont-elles modifiées après avoir déplacé des fichiers vers un NAS ?

Les fichiers peuvent fonctionner normalement sur un ordinateur, un disque externe ou un dossier de téléchargement, puis devenir en lecture seule, invisibles pour une application ou inaccessibles après leur déplacement vers un NAS. Cela ne signifie généralement pas que les données du fichier sont endommagées. Cela signifie que les fichiers sont entrés dans un nouveau système de fichiers avec un modèle de propriété et de permissions différent.

Un déplacement entre périphériques est souvent effectué comme une copie suivie de la suppression de la source. Le NAS crée de nouveaux fichiers en utilisant l'identité SMB ou NFS connectée, les ACL du dossier de destination, les valeurs UID et GID, le umask, l'utilisateur du conteneur et les règles de création côté serveur. La manière la plus rapide de résoudre le problème est d'identifier qui a créé les fichiers, qui en est le propriétaire maintenant, et quel utilisateur ou processus se voit refuser l'accès.

Déplacer des fichiers vers un NAS crée généralement de nouveaux fichiers

Glisser un dossier vers un NAS peut ressembler à un déplacement ordinaire dans l'Explorateur Windows ou Finder. En réalité, le disque source et le NAS sont des systèmes de fichiers distincts. Le client lit les données originales, crée de nouveaux objets de destination, puis supprime les originaux après la réussite du transfert.

Cela diffère du déplacement d'un fichier entre deux dossiers sur le même système de fichiers, où le système peut simplement mettre à jour l'emplacement du fichier dans le répertoire. La description de Microsoft sur le comportement de copie et déplacement explique que les objets copiés vers un autre volume héritent des permissions du nouveau dossier, tandis qu'un déplacement sur le même volume conserve normalement les permissions existantes.

Cette distinction explique pourquoi « Couper et Coller » ne garantit pas que la propriété, les entrées ACL ou les attributs étendus restent identiques après un transfert vers un NAS. Le système de destination ne fait pas que déplacer l'objet original du système de fichiers.

Les ACL de destination déterminent ce que les nouveaux fichiers héritent

Si chaque nouveau fichier copié reçoit les mêmes permissions inattendues, le répertoire parent est généralement plus important que le fichier source. La destination peut avoir hérité d'entrées ACL, d'ACL POSIX par défaut, de drapeaux ACL NFSv4 ou de préréglages de permissions spécifiques au NAS.

Par exemple, un dossier partagé peut être configuré de manière à ce que les nouveaux fichiers héritent des accès pour un groupe familial, un groupe média ou un compte SMB particulier. L'absence d'un indicateur d'héritage peut produire l'effet inverse : les utilisateurs peuvent accéder à la racine du jeu de données mais pas aux nouveaux fichiers qu'il contient.

Les systèmes de permissions de type TrueNAS distinguent les modèles POSIX et NFSv4/SMB ACL. Le comportement important est que l'héritage des ACL NFSv4 et SMB peut contrôler les nouveaux fichiers et dossiers, tandis que les valeurs par défaut POSIX et les limites des datasets se comportent différemment. Avant de modifier des fichiers individuels, inspectez l'ACL et les drapeaux d'héritage sur le dossier de destination.

Le NAS utilise le compte SMB connecté

Lorsqu'un ordinateur Windows ou macOS copie un fichier via SMB, le NAS ne conserve normalement pas l'identité locale de l'utilisateur du client. Il crée le fichier de destination avec le compte authentifié sur le partage SMB, ou avec un compte auquel cette session est mappée.

C'est pourquoi un fichier possédé par un utilisateur Windows sur le PC source peut être possédé par kenneth, utilisateurnas, invité, ou une autre identité côté NAS après le transfert. Un identifiant SMB enregistré peut aussi faire qu'un ordinateur crée des fichiers sous un propriétaire différent d'un autre ordinateur.

Vérifiez le nom d'utilisateur SMB actif plutôt que de supposer que la connexion du bureau est utilisée. Déconnectez le partage, effacez les identifiants obsolètes si nécessaire, et reconnectez-vous avec le compte NAS qui devrait posséder ou gérer les fichiers.

L'accès au partage et l'accès aux fichiers sont des couches de permission distinctes

Un utilisateur peut ouvrir le partage SMB et parcourir les dossiers mais ne pas pouvoir modifier, renommer ou supprimer un fichier. Cela signifie que le partage réseau est accessible ; cela ne prouve pas que le système de fichiers a accordé l'opération demandée.

Les règles au niveau du partage déterminent si un client SMB ou NFS peut accéder au partage et si la connexion est en lecture seule ou lecture/écriture. Le système de fichiers sous-jacent évalue ensuite le propriétaire, le groupe, les bits de mode, les entrées ACL et les règles d'héritage pour chaque fichier et dossier.

Dépannez les deux couches. Un partage marqué en lecture/écriture ne peut pas outrepasser une ACL système de fichiers qui refuse l'écriture, et des modes système permissifs ne servent à rien si le compte SMB est restreint par la configuration du partage.

Les ACL de style Windows et les modes POSIX ne correspondent pas parfaitement

les permissions Windows peuvent contenir plusieurs utilisateurs et groupes, des entrées explicites d'autorisation et de refus, des drapeaux d'héritage, et des droits séparés pour la lecture, l'écriture, la suppression et la modification. Les bits de mode POSIX traditionnels réduisent l'accès au propriétaire, au groupe et aux autres.

Samba et les systèmes d'exploitation NAS doivent traduire entre ces modèles. Un panneau de sécurité Windows peut afficher une ACL détaillée même si ls -l affiche seulement une représentation simplifiée. Inversement, exécuter chmod peut modifier les bits de mode sans reconstruire correctement l'ACL de style Windows attendue par les clients SMB.

Si le dataset NAS utilise des ACL NFSv4 ou SMB, inspectez l'ACL complète via l'interface NAS ou une commande compatible ACL. Ne supposez pas qu'un fichier affichant rwxrwx--- expliquent toute l'histoire des permissions.

Les incompatibilités UID et GID affectent Linux, NFS et les applications

Les systèmes Linux déterminent généralement la propriété via les identifiants numériques d’utilisateur et de groupe. Le nom d’utilisateur n’est qu’une étiquette associée à ces numéros.

Deux systèmes peuvent tous deux afficher un utilisateur appelé media alors que l’un utilise l’UID 1000 et l’autre l’UID 1001. Pour Linux et NFS, ce sont des identités différentes. Un fichier appartenant à l’UID 1000 peut être inaccessible à une application s’exécutant en UID 1001 même si leurs noms d’utilisateur visibles semblent identiques.

Vérifiez les valeurs numériques sur le NAS, l’hôte, le client et l’application :

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

Comparez les numéros plutôt que seulement les noms affichés. Si plusieurs systèmes doivent écrire sur le même stockage, alignez les valeurs UID/GID requises ou créez un groupe partagé avec les permissions correctes.

SMB et NFS peuvent écrire le même ensemble de données en tant qu’utilisateurs différents

Les problèmes de permission apparaissent souvent progressivement lorsque les clients SMB et NFS ont tous deux un accès en écriture au même répertoire. Les fichiers téléchargés via SMB peuvent appartenir à un utilisateur NAS, tandis que les fichiers créés via NFS peuvent porter un UID numérique d’un autre système.

Les deux protocoles peuvent aussi appliquer des règles différentes d’ACL et de mappage d’identité. En conséquence, un dossier peut contenir des fichiers qui semblent identiques pour un utilisateur mais ont des propriétaires, groupes, masques ou entrées héritées différents.

Choisissez un protocole d’écriture principal lorsque c’est possible. Lorsque SMB et NFS doivent partager un ensemble de données, alignez les ID numériques, les groupes partagés, les ACL par défaut, les valeurs umask et le comportement de création avant d’y placer des données en production.

Les conteneurs Docker ajoutent une autre identité utilisateur

Un fichier peut être lisible via SMB mais inaccessible à Plex, Jellyfin, Nextcloud, un téléchargeur ou un conteneur de sauvegarde. Docker peut monter le chemin correct alors que le processus à l’intérieur du conteneur n’a toujours pas la permission de le lire ou de l’écrire.

Un processus de conteneur s’exécute sous un UID et un GID propres. Si cette identité ne correspond pas au propriétaire ou à un groupe autorisé sur le chemin NAS monté, l’application reçoit Permission refusée. Un montage de volume rend le répertoire visible ; il ne contourne pas l’autorisation du système de fichiers.

Une solution courante consiste à faire correspondre l’UID et le GID du conteneur avec l’identité autorisée à utiliser le volume monté. Vérifiez l’identité réelle du processus plutôt que de vous fier uniquement à un champ PUID ou PGID affiché dans un fichier Compose :

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "Writable"

Un conteneur peut créer des fichiers qu’un autre ne peut pas lire

Cela arrive fréquemment dans les piles d'automatisation des médias. Un conteneur de téléchargement écrit avec succès un fichier terminé, mais le serveur média ne peut pas le scanner, ou un organisateur ne peut pas le renommer.

Les applications peuvent utiliser des valeurs UID/GID différentes ou des umasks différents. Si le téléchargeur crée des fichiers en tant que 600, seul son propriétaire peut les lire et les écrire. Un mode tel que 640 autorise la lecture par le groupe, mais seulement lorsque les deux applications partagent le groupe correct.

Pour les répertoires d'applications partagés, utilisez un groupe propriétaire planifié, ajoutez les identités nécessaires de l'application à ce groupe, et sélectionnez un umask qui donne au groupe l'accès requis. Corriger seulement les anciens fichiers ne suffira pas si le téléchargeur continue de créer de nouveaux fichiers avec des modes restrictifs.

Umask et règles de création serveur contrôlent les nouvelles permissions

Si les anciens fichiers fonctionnent mais que chaque nouveau fichier est inaccessible, le processus de création est probablement la cause. Chaque programme commence avec un mode de fichier demandé, et son umask retire certaines permissions avant la création du fichier.

Samba peut aussi utiliser des réglages tels que masque de création, masque de répertoire, forcer l'utilisateur, ou forcer le groupe. Les interfaces NAS peuvent cacher ces options derrière des modèles de permissions, des préréglages de dossiers partagés ou des options d'héritage.

Créez un fichier test via chaque chemin : Windows SMB, macOS SMB, gestionnaire de fichiers NAS, NFS, et chaque conteneur pertinent. Comparez le propriétaire, le groupe, le mode et l'ACL résultants. Cela révèle rapidement quel chemin de création produit les permissions erronées.

Différents outils de transfert préservent différentes métadonnées

Finder, l'Explorateur Windows, une interface web NAS, cp, et rsync ne garantissent pas des résultats identiques. Certains préservent les horodatages, d'autres peuvent conserver les modes POSIX, et d'autres créent simplement de nouveaux fichiers selon les règles de la destination.

Avant de choisir une méthode de migration, décidez quelles propriétés doivent être conservées :

• Contenu des fichiers et structure des répertoires
• Horodatages de modification
• Permissions POSIX
• Propriétaire et groupe
• Entrées ACL
• Attributs étendus
• Liens symboliques

Pour des documents familiaux ordinaires ou des fichiers médias, l'héritage de la destination peut être préférable à la préservation des comptes informatiques source qui n'existent pas sur le NAS. Pour les données d'application, les répertoires personnels Linux ou les migrations de serveurs, la préservation de la propriété et des métadonnées ACL peut être essentielle.

Rsync ne préserve pas tous les attributs avec une seule commande basique

Rsync est utile pour des migrations NAS contrôlées, mais le résultat dépend de ses options, des privilèges de l'utilisateur exécutant la commande et des capacités des systèmes de fichiers source et destination.

Le mode archive préserve les métadonnées courantes, y compris les modes, les horodatages, les groupes et la propriété lorsque cela est permis. Des options supplémentaires sont nécessaires lorsque la migration doit préserver les permissions, ACL et attributs étendus avec rsync. Un test typique de Linux à Linux peut utiliser :

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

Le -A l'option préserve les ACL et -X préserve les attributs étendus lorsque les deux côtés les supportent. --numeric-ids doit être utilisé délibérément car préserver un propriétaire numérique qui n'a pas de compte valide sur le NAS peut reproduire le décalage que vous essayez d'éviter.

Une destination rsync montée en SMB peut ne pas se comporter comme le système de fichiers NAS

Exécuter rsync depuis un ordinateur vers un partage SMB monté localement n'est pas toujours équivalent à exécuter rsync via SSH directement sur le système de fichiers NAS. La couche SMB peut mapper les propriétaires, transformer les ACL ou rejeter les tentatives de définir des attributs.

L'utilisateur effectuant la copie SMB peut ne pas avoir la permission d'assigner une propriété arbitraire, même lorsque rsync le demande. Le système de fichiers de destination peut aussi supporter un modèle ACL différent de la source.

Testez d'abord un petit répertoire représentatif. Examinez les fichiers directement sur le NAS après le transfert, pas seulement via le partage monté du client. Confirmez la propriété, les modes, les ACL, les attributs étendus et l'accès des applications avant de migrer l'ensemble du dataset.

Les préréglages de permissions NAS peuvent remplacer les bits de mode simples

Certains systèmes NAS gèrent l'accès via des modèles ACL de dataset et des métadonnées étendues plutôt que seulement par les modes traditionnels propriétaire/groupe/autres. Cela peut rendre une gestion manuelle chmod peuvent sembler réussies alors que SMB ou une application continue de refuser l'accès.

Un dataset peut également être configuré pour réappliquer les règles héritées lors de la création de nouveaux fichiers ou lors de la modification des permissions via l'interface de gestion. Mélanger des ACL gérées par l'interface graphique avec des modifications répétées en ligne de commande peut produire un état incohérent.

Choisissez un modèle de permission et gérez-le de manière cohérente. Si le dataset est configuré pour une ACL SMB/NFSv4, utilisez l'éditeur ACL du NAS ou des outils compatibles ACL au lieu de remplacer à plusieurs reprises la structure avec des commandes en mode POSIX.

Réinstaller le NAS ne réinitialise pas nécessairement les permissions des données

Les permissions appartiennent généralement aux fichiers et au dataset du système de fichiers, pas seulement à la configuration du système d'exploitation NAS. Réinstaller le système de démarrage peut donc laisser les mêmes entrées de propriété et ACL inaccessibles sur un pool de stockage importé.

Un cas communautaire TrueNAS illustre comment les permissions du système de fichiers restent attachées au pool de stockage et doivent correspondre aux utilisateurs et à la configuration d'accès corrects. Il montre également le risque de faire de grands changements récursifs sans d'abord comprendre le modèle d'identité prévu.

Avant de réinstaller ou de reconstruire des services, inspectez le propriétaire du jeu de données, le groupe, l’ACL et les utilisateurs de l’application. Les données peuvent être intactes et ne nécessiter que la restauration correcte de leurs règles d’accès.

Pourquoi le chmod 777 récursif n’est pas une vraie solution

Lorsque des milliers de fichiers deviennent inaccessibles, chmod -R 777 semble être un moyen rapide de restaurer l’accès. Il accorde les permissions de lecture, écriture et exécution au propriétaire, au groupe et à toutes les autres identités locales.

Cela peut exposer des données privées, permettre à des services non liés de modifier des fichiers, définir la permission d’exécution sur des documents ordinaires et endommager une structure ACL héritée avec soin. Cela ne corrige pas non plus le mauvais propriétaire, l’UID de conteneur non apparié, l’absence d’appartenance au groupe ou le mauvais mappage d’identité SMB.

Utilisez plutôt le modèle d’accès prévu : établissez le propriétaire correct et le groupe partagé, reconstruisez l’ACL appropriée, définissez séparément les modes des répertoires et fichiers, et corrigez l’héritage futur et les paramètres umask. Testez sur un petit dossier avant d’appliquer des modifications récursives.

Réparer les permissions en partant de l’identité

Commencez par l’utilisateur ou le processus refusé plutôt que par la commande que vous espérez voir fonctionner. Un utilisateur SMB humain, un serveur média et un conteneur de sauvegarde peuvent nécessiter différents niveaux d’accès.

Pour chaque flux de travail affecté, enregistrez :

• L’utilisateur ou le processus tentant l’accès
• Son UID et GID numériques le cas échéant
• Le protocole ou le montage utilisé
• Le propriétaire et le groupe actuels du fichier
• L’ACL complète et les entrées héritées
• L’accès réellement requis : lecture, création, modification ou suppression

Puis modifiez uniquement la couche erronée. Ajoutez l’utilisateur à un groupe autorisé, corrigez la propriété, réparez l’ACL, alignez un UID de conteneur ou mettez à jour la règle de création. Évitez d’accorder un accès plus large que nécessaire au flux de travail.

Suivre un ordre de dépannage en couches

Modifier en même temps l’ACL du partage, l’identité du conteneur, l’export NFS et les modes de fichier détruit des preuves utiles. Testez une couche de permission à la fois.

Commencez avec un fichier affecté et un utilisateur ou une application affectée. Une fois ce petit cas résolu, créez un nouveau fichier via le flux de travail normal et confirmez que la correction empêche également le retour du problème.

Prévenez les problèmes de permissions avant une grande migration NAS

Réparer les permissions sur des centaines de milliers de fichiers est bien plus difficile que de tester le modèle d’accès avant la migration. Créez un petit dossier de destination avec la même ACL et configuration applicative prévue pour le jeu de données final.

Copiez plusieurs types de fichiers, des répertoires imbriqués, des fichiers en lecture seule, des scripts exécutables et des fichiers avec attributs étendus. Testez-les depuis chaque chemin requis : SMB, NFS, l’interface NAS, le logiciel de sauvegarde et les conteneurs concernés.

Ne commencez la migration complète que lorsque les nouveaux fichiers reçoivent systématiquement le bon propriétaire, groupe, ACL et accès applicatif. Gardez un instantané ou une sauvegarde avant d’appliquer des modifications récursives de propriété ou de permissions aux données existantes.

Conclusion finale

Les permissions des fichiers se cassent après le transfert vers un NAS car ce transfert crée généralement de nouveaux objets système de fichiers. Ces objets sont régis par le compte NAS utilisé pour le transfert, l’ACL de destination, les valeurs UID/GID, l’umask, le mappage de protocole et l’identité de l’application ou du conteneur.

Ne commencez pas par chmod 777Commencez par répondre à trois questions : qui a créé le fichier, qui en est le propriétaire maintenant, et quelle identité se voit refuser l’accès. Ensuite, inspectez l’accès au partage, les ACL du système de fichiers, l’héritage, les IDs du conteneur et les règles de création futures.

Une réparation réussie doit faire deux choses : restaurer l’accès approprié aux fichiers existants et garantir que le prochain fichier copié, téléchargé ou créé sur le NAS reçoive automatiquement les bonnes permissions.

FAQ

Pourquoi les fichiers copiés héritent-ils des permissions du dossier NAS ?

Un transfert vers un NAS crée généralement de nouveaux fichiers sur un autre système de fichiers. Les nouveaux objets reçoivent habituellement des permissions issues de l’ACL du dossier de destination, des drapeaux d’héritage et des règles de création côté serveur.

Pourquoi puis-je ouvrir des fichiers NAS via SMB mais pas mon conteneur Docker ?

La session SMB et le conteneur utilisent des identités différentes. Vérifiez l’UID et le GID réels du conteneur, la propriété numérique du chemin monté, l’appartenance au groupe et si le montage est en lecture seule.

Dois-je utiliser chmod 777 pour réparer un partage NAS ?

Non. Il accorde un accès large à chaque identité locale, peut endommager l’héritage des ACL et ne résout pas la propriété incorrecte ni le mappage UID/GID. Définissez les utilisateurs et groupes prévus, puis réparez la propriété et les ACL en conséquence.

Est-ce que rsync peut préserver les permissions des fichiers NAS ?

Il peut préserver les permissions POSIX et autres métadonnées lorsque les options sélectionnées, les privilèges d’exécution et les deux systèmes de fichiers les supportent. Les ACL et attributs étendus nécessitent des options supplémentaires telles que -A et -X.

Pourquoi les nouveaux fichiers continuent-ils de se casser après que j’ai réparé les anciens fichiers ?

Le chemin de création est toujours incorrect. Vérifiez l’ACL héritée du dossier de destination, l’identité SMB ou NFS, l’umask de l’application, les règles de création Samba et l’UID/GID du conteneur.