Pourquoi un partage NAS affiche-t-il d’anciens fichiers après le remplacement du dossier ?
Un partage NAS peut afficher d’anciens fichiers lorsque le client ou le service de partage pointe encore vers l’état mis en cache d’un répertoire ou vers l’ancien chemin.
Remplacer un dossier sur le NAS ne garantit pas que chaque session SMB, application, montage, chemin indirect ou espace de noms bascule immédiatement vers la nouvelle arborescence. Le serveur peut encore exporter l’ancien chemin, le remplacement peut avoir été effectué sous un autre point de montage, ou le client peut conserver les métadonnées du répertoire, les informations sur les fichiers, des handles ouverts ou une référence mise en cache. Le diagnostic le plus sûr consiste à comparer la vue du système de fichiers, la cible active du partage et une session client entièrement nouvelle avant de modifier un quelconque paramètre de cache.
Confirmez quelle couche affiche encore l’ancienne arborescence
Comparez le client SMB concerné avec le shell du NAS, le gestionnaire de fichiers web du NAS et un second client qui n’a pas ouvert le partage récemment. Notez un nom de fichier qui devrait avoir disparu et un nouveau nom de fichier qui devrait être visible.
Si le shell du NAS et le gestionnaire de fichiers web affichent eux aussi l’ancienne arborescence, le problème se situe en dessous de SMB : le remplacement a été effectué dans le mauvais répertoire, un montage attendu est absent ou un autre jeu de données masque le chemin. IBM indique que les notifications de modification SMB dépendent de la manière dont les changements parviennent au service de fichiers ; un seul client obsolète ne suffit donc pas à prouver que les données du serveur sont anciennes.
Ne vous contentez pas d’actualiser plusieurs fois le même navigateur de fichiers en considérant chaque actualisation comme un nouveau test. Une comparaison pertinente utilise un autre processus client, une autre session utilisateur ou une vue directe du système de fichiers local qui ne réutilise pas les mêmes métadonnées SMB.
Vérifiez la cible active du partage après le remplacement du dossier
Examinez la configuration des partages du serveur et déterminez à quel objet réel du système de fichiers correspond le chemin exporté. Vérifiez les montages bind, les liens symboliques, les points de montage des jeux de données, les mappages de volumes des conteneurs et si le dossier de remplacement a été créé avant ou après l’activation d’un montage de stockage.
Un problème fréquent survient lorsque l’administrateur remplace des fichiers dans un répertoire non monté, puis que le véritable montage de stockage est rétabli et masque ce remplacement. Le manuel Linux consacré à mount explique que le montage masque l’ancienne vue du répertoire tandis que le système de fichiers reste attaché ; c’est pourquoi le chemin visible doit être vérifié par rapport à la table des montages actifs.
Le guide de migration des données NAS de ZimaSpace fournit la séquence de vérification complémentaire permettant de confirmer que les chemins source et destination prévus contiennent les données attendues avant de supprimer l’ancienne copie.
Testez les caches SMB des répertoires et des informations de fichiers
Fermez toutes les applications qui utilisent le partage, déconnectez le mappage SMB et établissez une nouvelle session. Comparez le résultat avec un second ordinateur ou une nouvelle session utilisateur qui n’a pas encore parcouru le répertoire.
Les clients SMB Windows peuvent mettre en cache les métadonnées des répertoires et les informations sur les fichiers pendant une durée configurée. Les recommandations de Microsoft relatives à l’optimisation des serveurs de fichiers expliquent que la durée de vie du cache des répertoires détermine combien de temps les métadonnées peuvent rester en cache lorsque les baux de répertoire ne sont pas disponibles.
Si une nouvelle session affiche immédiatement la bonne arborescence alors que l’ancienne ne l’affiche pas, les données ne sont pas manquantes et la cible du partage est probablement correcte. Reconnectez proprement le client concerné et cherchez pourquoi sa session n’a pas reçu ou pris en compte la notification de modification attendue avant de modifier globalement les valeurs du cache.
Vérifiez les handles ouverts, les baux et les applications persistantes
Répertoriez les sessions SMB actives et les fichiers ouverts sur le NAS. Les gestionnaires multimédias, applications photo, outils de sauvegarde, fenêtres de terminal, indexeurs et navigateurs de fichiers peuvent conserver des répertoires ou des fichiers ouverts longtemps après la fin visible de l’opération de copie.
Fermez d’abord l’application, puis déconnectez uniquement la session SMB concernée. La documentation SMB de NetApp explique que les oplocks de bail préservent l’état du cache client ; désactiver les baux sur l’ensemble du NAS constitue donc une modification bien plus importante que la réinitialisation d’une seule connexion obsolète.
Si l’ancienne arborescence ne disparaît qu’après la fermeture d’une application précise, conservez ce résultat et testez à nouveau l’application avec le nouveau dossier. La correction doit porter sur son comportement de reconnexion, de surveillance ou d’actualisation, et non sur le pool de stockage.
Écartez les références DFS et les noms de serveurs en double
Vérifiez si le client a atteint le NAS via un nom d’hôte direct, une adresse IP, un alias DNS, un espace de noms DFS ou un ancien nom de serveur qui pointe désormais ailleurs. Deux chemins qui semblent similaires dans le navigateur de fichiers peuvent aboutir à des cibles de partage différentes.
Les clients DFS mettent en cache les références d’espace de noms et de dossiers pendant une durée définie. Ils peuvent également conserver ces références pendant un certain temps, ce qui peut temporairement diriger un client vers une ancienne cible après une modification de l’espace de noms.
Comparez l’identité du serveur, l’adresse résolue, le nom du partage et le chemin final des sessions fonctionnelle et obsolète. Ne videz pas tous les caches DNS et DFS avant d’avoir établi que le client concerné atteint une cible différente.
Comparez un chemin direct récent avec le chemin utilisateur habituel
Ouvrez le partage une fois avec le nom d’hôte habituel et une fois avec l’adresse directe vérifiée du serveur depuis une session client propre. Utilisez cette méthode uniquement pour distinguer les causes, et non comme remplacement permanent d’un nom d’hôte géré.
Si le chemin direct affiche la nouvelle arborescence tandis que le nom habituel affiche l’ancienne, concentrez-vous sur les alias, les références, les identifiants enregistrés ou un second NAS utilisant le même nom. Le modèle de chemin de mount.cifs de Debian montre pourquoi il faut comparer exactement la cible serveur/partage et le point de montage local, plutôt que de se fier à un nom d’affichage familier.
Comparez également le nombre de fichiers et le hash d’un fichier entre le chemin local du NAS et le chemin SMB. La correspondance avec l’ancien fichier confirme un problème de sélection du chemin ou du cache ; un fichier différent portant le même nom indique plutôt un remplacement incomplet, des dossiers en double ou du contenu généré par une application.
Corrigez le problème au niveau le plus précis et vérifiez sa persistance après redémarrage
Corrigez la cible du partage lorsqu’elle exporte le mauvais dossier, rétablissez le montage manquant lorsque le chemin est incorrectement masqué, reconnectez la session client obsolète lorsqu’un seul client est concerné, ou mettez à jour la cible DFS lorsque l’espace de noms référence encore l’ancien emplacement.
Évitez de modifier la durée de vie des caches SMB, de désactiver les baux ou de recréer le partage, sauf si un test contrôlé prouve que cette couche est responsable. La vue des sessions et verrous actifs de Samba permet de vérifier la connexion concernée avant d’appliquer une modification à l’échelle du serveur.
Le problème est résolu lorsque le shell du NAS, le gestionnaire de fichiers web, une nouvelle session SMB et le chemin client habituel affichent tous le même contenu de dossier après le redémarrage du service et de l’hôte. Laissez l’ancien dossier hors ligne mais intact jusqu’à la réussite de cette vérification et assurez-vous qu’aucune application ne continue d’y écrire.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
