Que devez-vous vérifier lorsqu'un partage NAS devient soudainement en lecture seule ?

Lorsqu’un partage NAS devient soudainement en lecture seule, déterminez d’abord si la restriction existe au niveau du client, du partage, du dataset, du système de fichiers monté ou du pool de stockage. La réponse correcte dépend de l’endroit où les écritures sont bloquées.

Ne forcez pas un remontage ni ne lancez une réparation du système de fichiers en premier. Un état en lecture seule peut être une réponse protectrice délibérée à des erreurs d’E/S, des dommages aux métadonnées, un arrêt non sécurisé, un volume plein ou un chemin de stockage dégradé.

Le problème est-il limité à un utilisateur, un partage ou à tout le volume ?

Testez avec un petit nouveau fichier via le chemin client normal, puis comparez avec un autre utilisateur autorisé, un autre client et un autre partage sur le même volume. Notez l’erreur exacte au lieu de vous fier à la case graphique « lecture seule » d’un dossier.

Si un utilisateur échoue alors qu’un autre écrit avec succès, examinez l’identité, l’appartenance au groupe, l’héritage ACL, le quota et les identifiants mis en cache. Le guide sur les permissions de fichiers NAS cassées aide à distinguer les causes ACL et identité.

Testez également l’administration locale sur le NAS si la plateforme le permet. Une écriture locale réussie alors que SMB échoue indique la couche de partage ; une erreur locale « système de fichiers en lecture seule » indique une couche inférieure.

Quelle couche correspond au symptôme ?

Utilisez la couche la plus étroite qui explique toutes les observations. Modifier les permissions ne réparera pas un système de fichiers monté en lecture seule par le noyau, et un remontage ne corrigera pas une identité SMB refusée.

Cette séparation évite les dépannages destructeurs. Conservez les captures d’écran, les horodatages et les journaux avant de redémarrer les services, car un redémarrage peut effacer des preuves utiles même s’il restaure temporairement l’accès.

La capacité, les quotas ou les réservations de snapshot pourraient-ils bloquer les écritures ?

Vérifiez l'espace libre au niveau du pool et du volume, pas seulement à l'intérieur du partage. La provision fine, les réservations d'instantanés, l'espace des métadonnées ou une partition système NAS pleine peuvent bloquer les écritures alors qu'un client rapporte encore une capacité apparente.

Un quota utilisateur, groupe ou dossier partagé peut provoquer une erreur d'écriture locale. Comparez le quota de l'identité affectée avec un compte fonctionnel connu et vérifiez si une application a rempli un ensemble de données privé.

Si le volume est presque plein, arrêtez les écrivains non essentiels et créez une sauvegarde vérifiée avant le nettoyage. Supprimer des fichiers au hasard peut ne pas libérer d'espace lorsque des instantanés ou des corbeilles conservent les blocs.

Que révèlent l'état du montage et les journaux système ?

Sur un NAS basé sur Linux, vérifiez si le système de fichiers concerné est monté avec ro et examinez les messages actuels du noyau pour les erreurs de système de fichiers, de périphérique, de délai d'attente et d'E/S. Une séquence structurée de dépannage des erreurs de système de fichiers en lecture seule commence par l'état du montage et les journaux plutôt que par une réparation immédiate.

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
dmesg | grep -iE 'lecture seule|Erreur d'E/S|ext4|xfs|btrfs|nvme|ata'

Un remontage en lecture seule protecteur est une conséquence, pas la cause première. Après une coupure de courant, suivez les premiers contrôles pour un volume NAS en lecture seule avant de tenter une réparation.

Exportez les journaux avant de redémarrer. Si la plateforme gère le système de fichiers, suivez sa procédure de support plutôt que d'appliquer des commandes de réparation génériques sur un volume d'appareil en fonctionnement.

Faut-il remonter le système de fichiers en lecture-écriture ?

Pas avant que la cause soit comprise. Forcer l'accès en lecture-écriture peut reprendre les écritures d'application sur un système de fichiers instable et transformer une incohérence récupérable en un dommage plus étendu.

Un remontage est raisonnable uniquement lorsque l'option en lecture seule a été configurée intentionnellement ou que le processus de diagnostic du fournisseur confirme que le stockage sous-jacent est sain. Même dans ce cas, effectuez une sauvegarde actuelle et conservez les journaux.

En cas d'erreurs d'E/S ou de système de fichiers, réduisez l'activité et préservez l'état. La réparation peut nécessiter une vérification hors ligne, un remplacement du disque, une importation du pool ou une récupération assistée par le support.

Comment tester les permissions et les paramètres SMB ?

Lorsque les écritures locales fonctionnent, inspectez les paramètres lecture seule au niveau du partage, les ACL effectives, les refus hérités, le mappage d'identité et les sessions client mises en cache. Un partage SMB devenant lecture seule documenté montre pourquoi tester les utilisateurs et les journaux Samba peut isoler une faute au niveau de l'identité.

Créez un dossier de test temporaire avec une ACL documentée plutôt que de réécrire les permissions sur tout le partage. Si le dossier de test fonctionne, comparez son propriétaire, groupe, héritage et propriétés du dataset avec le chemin défaillant.

Évitez les réinitialisations récursives des permissions pendant le diagnostic. Elles peuvent casser la propriété des applications, effacer des restrictions intentionnelles et créer un second incident sans lien avec la cause initiale de lecture seule.

Quelle est la séquence de récupération la plus sûre ?

1. Arrêtez ou mettez en pause les applications qui écrivent sur le partage affecté.
2. Enregistrez la portée, les erreurs, l’état du pool, les indicateurs de montage, la capacité et les événements récents.
3. Exportez les journaux et vérifiez la sauvegarde indépendante la plus récente.
4. Séparez les causes client, identité, partage, dataset, système de fichiers et matériel.
5. Appliquez la correction la plus petite prise en charge à la couche confirmée.
6. Testez les écritures dans un dossier contrôlé et vérifiez la santé du système de fichiers.
7. Réactivez les services progressivement tout en surveillant les journaux.

Si le pool est dégradé ou que les erreurs persistent, arrêtez-vous après la collecte des preuves et escaladez. Les redémarrages, reconstructions ou tentatives de réparation répétées peuvent écraser les preuves nécessaires à la récupération.

FAQ

Un partage NAS peut-il être en lecture seule même si le volume est sain ?

Oui. La configuration du partage, les ACL, les quotas, le mappage d'identité ou les identifiants client peuvent bloquer les écritures alors que le système de fichiers et le pool restent sains.

Redémarrer un NAS résout-il un partage en lecture seule ?

Cela peut résoudre un problème de service ou de montage, mais cela peut aussi effacer des preuves volatiles et ne répare pas la cause sous-jacente. Capturez d'abord l'état et les journaux.

Un système de fichiers en lecture seule signifie-t-il que le disque est défaillant ?

Pas toujours. Cela peut résulter d'erreurs de système de fichiers, d'un arrêt non sécurisé, de la configuration de montage ou de problèmes de contrôleur, mais la santé du disque et les journaux d'E/S doivent être vérifiés rapidement.

Considérez le mode lecture seule comme un signal de limite. Identifiez la couche exacte, protégez les données et ne restaurez les écritures qu'après vérification de la cause et du chemin de récupération.