Le partage NAS affiche d’anciens fichiers après le remplacement du stockage : vérifications et solutions

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Les anciens fichiers après un remplacement du stockage proviennent généralement d'un chemin monté incorrect, d'une exportation qui pointe encore vers l'ancienne arborescence, d'une session SMB obsolète ou d'une identité de serveur en double.

Commencez par choisir un nom de fichier qui devrait disparaître et un autre qui devrait apparaître, puis comparez le système de fichiers local du NAS, la cible d'exportation active, une session client réellement nouvelle et l'adresse du serveur à laquelle cette session s'est connectée. Cet ordre permet de distinguer les problèmes de stockage et d'espace de noms de la mise en cache côté client, sans risquer d'écrire dans deux copies. Conservez les deux ensembles de stockage intacts jusqu'à ce que la correction correspondante résiste au rechargement d'un service, au redémarrage du NAS et à l'accès depuis deux clients.

Comparer le stockage de remplacement avec la vue du NAS local

Choisissez un ancien nom de fichier qui devrait avoir disparu et un nouveau nom de fichier qui doit apparaître. Vérifiez les deux depuis le shell du NAS et le gestionnaire de fichiers web, notez le périphérique ou le jeu de données monté, le point de montage, l'identifiant du système de fichiers, l'état du pool et les hachages des fichiers, puis comparez-les au manifeste de migration.

Un workflow de protection des migrations NAS ZimaSpace conserve la source, la destination et la copie de vérification intactes jusqu'à ce que les nombres d'éléments et les données représentatives correspondent. Appliquez cette limite ici avant de supprimer l'ancien pool ou de modifier le partage : un contenu obsolète peut indiquer que le remplacement n'a jamais été monté à l'endroit prévu.

Si le NAS lui-même affiche l'ancienne arborescence, examinez l'ordre des montages, les montages automatiques ayant échoué, les montages bind, les points de montage des jeux de données et un répertoire masqué sous un autre montage. N'effacez pas les caches clients tant que le chemin côté serveur et l'identité du périphérique ne correspondent pas au remplacement prévu.

Vérifier la cible active du partage et l'espace de noms

Lisez la configuration active des exportations SMB ou NFS et résolvez les liens symboliques, les montages bind, les chemins des conteneurs et les alias jusqu'à l'emplacement final du système de fichiers. Comparez la cible d'exportation au point de montage de remplacement vérifié, et non à un nom convivial de partage qui a pu être conservé après la migration.

Dans un cas rapporté par la communauté Unraid, une comparaison entre partage de disque et partage utilisateur a permis de distinguer les fichiers présents dans les partages de disque d'une vue obsolète du partage utilisateur. Considérez cela comme un indicateur ciblé : si le chemin local direct ou le chemin du disque est à jour mais que l'espace de noms est ancien, corrigez la couche d'exportation plutôt que de recopier les données.

Rechargez uniquement le service de partage concerné après avoir enregistré sa configuration et vérifié qu'aucune écriture n'est en cours. Une réussite fait apparaître la nouvelle arborescence lors d'une nouvelle requête d'espace de noms locale ; en cas d'échec, rétablissez la configuration précédente du service tout en conservant les journaux des montages et de l'espace de noms.

Distinguer un client obsolète d'une session serveur obsolète

Ouvrez le partage depuis un deuxième client ou une nouvelle session utilisateur qui ne l'a jamais parcouru. Notez l'adresse du serveur, le nom du partage, les identifiants, le protocole négocié, les handles ouverts et les différences éventuelles entre les anciens et les nouveaux noms de fichiers selon les clients. Actualiser plusieurs fois le même navigateur de fichiers ne constitue pas un test de session propre.

Une discussion de la communauté Synology indique que le cache SMB modifie le symptôme : l'effacement du cache SMB ou le redémarrage de Samba a modifié le comportement observé. Utilisez cela comme indice qu'un cache de session ou de service peut être en cause, et non comme une raison de désactiver la mise en cache sur l'ensemble du NAS.

Fermez les applications qui possèdent des handles ouverts, déconnectez uniquement le mappage concerné, effacez les identifiants enregistrés ou les références uniquement lorsque cette piste est confirmée, puis reconnectez-vous. Si le client propre était déjà obsolète, revenez aux couches de cible et d'identité du serveur au lieu d'appliquer des modifications globales du registre côté client.

-15% OFF

Vérifier l'identité du serveur et valider la correction correspondante

Comparez les réponses DNS, les adresses IP, l'identité du serveur SMB, les alias, les références DFS, les routes VPN et les mappages enregistrés. Un NAS de remplacement peut réutiliser un nom convivial alors qu'une ancienne adresse, une ancienne cible d'espace de noms ou un conteneur continue de servir l'ancienne arborescence. Testez une adresse directe vérifiée uniquement comme moyen de distinction, et non comme contournement permanent.

Appliquez la correction minimale : corrigez la cible du montage ou de l'exportation, rechargez un seul partage, reconnectez un seul client, faites expirer une seule référence ou mettez à jour un seul enregistrement DNS. Comparez le nombre de fichiers et les hachages entre le chemin local et le partage, créez puis supprimez un fichier temporaire et vérifiez les autorisations attendues.

Redémarrez le service de partage et le NAS pendant une fenêtre de maintenance, puis reconnectez deux clients ainsi que l'application qui était initialement restée obsolète. Ne concluez que lorsque tous les chemins affichent la nouvelle arborescence après un redémarrage ; revenez en arrière si des écritures aboutissent dans des copies différentes et faites remonter les identités ambiguës avant d'effacer l'un ou l'autre ensemble de stockage.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.