Pourquoi un système de fichiers monté peut-il créer des fichiers, mais refuser les renommages ?

Un système de fichiers monté peut autoriser la création de fichiers tout en refusant les renommages, car le renommage obéit à des exigences distinctes concernant les répertoires, la propriété, les limites, les indicateurs et les descripteurs ouverts.

Un montage réussi prouve uniquement que le système de fichiers est attaché, et une écriture réussie prouve que le client peut créer ou modifier au moins un objet. Le renommage est une opération sur une entrée de répertoire qui peut nécessiter des autorisations sur les répertoires source et destination, des droits de suppression, un chemin sur le même système de fichiers, un nom de destination valide, ainsi qu’une absence de mode de partage SMB incompatible ou d’indicateur de fichier protégé. Relevez l’erreur exacte et comparez séparément la création, le renommage, le déplacement et la suppression avant de considérer le système de fichiers comme endommagé.

Relevez l’erreur exacte de renommage avant de modifier les autorisations

Répétez un même renommage depuis l’hôte et depuis le client concerné. Notez le chemin source, le chemin destination, l’identité de l’utilisateur, le système de fichiers, le point de montage, le code d’erreur et indiquez si le nom de destination existe déjà.

Les erreurs de l’appel système Linux rename distinguent les échecs d’autorisation, les points de montage occupés, les déplacements entre périphériques, les systèmes de fichiers en lecture seule, les destinations non vides et d’autres conditions qui peuvent sembler identiques dans un explorateur de fichiers graphique.

Si la création d’un nouveau fichier réussit mais que son renommage échoue, conservez cette différence. Elle oriente le diagnostic vers le remplacement d’une entrée de répertoire, les droits de suppression, les règles de nommage, les verrous ou une limite de chemin plutôt que vers un simple problème d’accès en écriture.

Vérifiez les autorisations sur les deux répertoires parents

Examinez la propriété, les bits de mode, les ACL et l’identité effective dans le répertoire contenant l’ancien nom ainsi que dans celui qui contiendra le nouveau. L’autorisation de renommer dépend principalement des répertoires, et non du bit d’écriture du fichier.

Red Hat explique que le sticky bit limite le renommage et la suppression dans les répertoires partagés accessibles en écriture au propriétaire du fichier, au propriétaire du répertoire ou à un utilisateur privilégié, même lorsque plusieurs utilisateurs peuvent y créer des fichiers.

Effectuez le test avec le même utilisateur NAS que celui qui reçoit l’erreur. La réussite avec un compte administrateur ne prouve pas que le compte standard dispose des droits de suppression ou de renommage sur les deux entrées de répertoire.

Vérifiez les indicateurs immuable, non supprimable et ajout seulement

Vérifiez les indicateurs du système de fichiers sur le fichier et ses répertoires parents, en plus des autorisations et ACL ordinaires. Des restaurations, outils de sécurité ou workflows de conservation peuvent préserver des indicateurs qui ne sont pas visibles dans une liste basique des autorisations.

Le manuel de sécurité de FreeBSD indique qu’un indicateur de fichier immuable empêche la modification ou la suppression, tandis que les indicateurs ajout seulement et non supprimable peuvent également bloquer les changements de répertoire nécessaires au renommage.

Ne supprimez un indicateur de protection qu’après avoir identifié la règle ou l’application qui l’a défini. Effacer les indicateurs globalement peut neutraliser les contrôles de conservation, de sauvegarde ou de protection contre les rançongiciels.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Écartez un déplacement entre systèmes de fichiers dissimulé derrière une même arborescence

Déterminez les identifiants de périphérique, points de montage, montages liés, jeux de données et chemins de conteneurs correspondant aux répertoires source et destination. Deux dossiers situés dans le même partage peuvent tout de même appartenir à des systèmes de fichiers montés différents.

La bibliothèque GNU C définit EXDEV comme une erreur de renommage entre périphériques. Un outil de déplacement de niveau supérieur peut récupérer la situation en copiant puis en supprimant, tandis qu’une application qui attend un renommage atomique peut simplement échouer.

Si un déplacement local ne réussit qu’en copiant le fichier entier, il ne s’agissait pas d’un renommage atomique. Corrigez les chemins temporaires et définitifs de l’application, ou conservez les deux étapes sur le même système de fichiers.

Vérifiez les descripteurs ouverts et le partage de suppression SMB

Répertoriez les fichiers ouverts et les sessions SMB pour les répertoires source et destination. Fermez un par un les visionneuses, générateurs de miniatures, éditeurs, analyseurs multimédias, outils antivirus et clients de sauvegarde.

Microsoft documente un cas de dossier réseau où un descripteur ouvert du cache des miniatures bloque le renommage, ce qui montre que la possibilité de lire ou de créer d’autres fichiers ne suffit pas à écarter une violation de partage sur l’objet concerné.

Ne redémarrez pas l’intégralité du NAS avant d’avoir conservé les informations sur les descripteurs ouverts. Un redémarrage peut libérer le verrou tout en masquant le client ou le service qui l’a recréé.

Comparez les règles de renommage SMB avec le nom de fichier du client

Testez un nom simple en minuscules et en caractères ASCII dans le même répertoire. Comparez ensuite les changements de casse uniquement, les caractères réservés, les points ou espaces finaux, la normalisation Unicode et l’existence d’un nom de destination.

Le module d’interopérabilité macOS de Samba fournit une option de compatibilité du renommage POSIX, ce qui illustre le fait que les règles de nommage du client et du serveur peuvent déterminer si un renommage de répertoire est accepté.

Si un seul modèle de nom échoue, conservez la correspondance avec le nom d’origine avant de le normaliser. Un renommage groupé sans liste de restauration peut interrompre les bibliothèques multimédias, les tâches de synchronisation, les raccourcis et les sauvegardes.

Réparez la couche concernée et vérifiez chaque opération

Corrigez uniquement la cause vérifiée : autorisation du répertoire parent, propriété liée au sticky bit, indicateur de protection, chemin sur le même système de fichiers, descripteur ouvert ou nom de fichier incompatible. Répétez le test avec l’utilisateur et l’application d’origine.

L’article de ZimaSpace sur les collisions de noms de fichiers différant uniquement par la casse traite du cas plus spécifique entre plateformes où deux noms deviennent équivalents sur la destination.

Le problème est résolu lorsque la création, la fermeture, le renommage, le déplacement, la suppression et la recréation réussissent tous sur le chemin prévu après reconnexion et redémarrage. Interrompez les écritures si le système de fichiers passe en lecture seule ou signale une corruption ou des erreurs d’E/S matérielles.

Foire aux questions

Pourquoi puis-je créer un fichier, mais pas le renommer ?

La création nécessite l’autorisation d’ajouter une entrée de répertoire, tandis que le renommage peut également exiger des droits de suppression sur l’ancienne entrée, des droits de lecture et d’exécution sur les deux répertoires parents, des règles de nommage compatibles et l’absence d’indicateurs de protection ou de descripteurs en conflit.

Une erreur de renommage EXDEV signifie-t-elle que le système de fichiers est endommagé ?

Non. Elle signifie généralement que la source et la destination se trouvent sur des systèmes de fichiers différents, et que le noyau ne peut donc pas effectuer un seul renommage atomique. Un déplacement par copie puis suppression peut néanmoins fonctionner.

Peut-on renommer un fichier ouvert ?

De nombreux systèmes de fichiers POSIX locaux l’autorisent, mais les clients SMB et les applications peuvent ouvrir des fichiers sans partager l’autorisation de suppression, ce qui amène le serveur à refuser le renommage jusqu’à la fermeture du descripteur.