Windows « Access is denied » sur dossier de sauvegarde NAS OpenMediaVault (SMB) : diagnostic et correctifs

Après réinstallation de Windows sur un nouveau SSD, l’accès au dossier \\NAS\Backup d’un NAS OpenMediaVault 5.5.6‑1 échoue avec « Access is denied ». Suivez ce guide pas‑à‑pas pour diagnostiquer la cause (SMB 2/3, identifiants, ACL) et rétablir l’accès sans affaiblir la sécurité.

Sommaire

Vue d’ensemble du problème

Scénario typique : Windows 10/11 fraîchement réinstallé ne parvient plus à ouvrir uniquement le partage de sauvegarde du NAS (\\NAS\Backup), alors que les autres partages restent accessibles. La boîte de dialogue d’authentification réapparaît en boucle ou se solde par l’erreur « Access is denied », parfois accompagnée du code 0x80070005. Le NAS est sous OpenMediaVault (OMV) 5.5.6‑1 avec Samba (SMB) activé.

Cette situation résulte en général d’un mélange de facteurs : identité Windows modifiée lors de la réinstallation, cache d’identifiants obsolètes, ACL spécifiques au dossier Backup, ou désalignement des paramètres SMB (protocole, règles NTLM). La bonne nouvelle : on peut corriger sans toucher à vos données.

Causes fréquentes après une réinstallation de Windows

Identité différente (SID, nom de session, type de compte). Windows tente d’abord une connexion transparente (SSO) avec l’utilisateur courant ; si l’OMV ne connaît pas exactement ce couple nom/mot de passe, l’authentification échoue.
Cache d’informations d’identification (Credential Manager) ou net use persistants pointant vers l’ancien couple nom/mot de passe ou un autre partage du même hôte.
ACL spécifiques au seul dossier Backup (droits POSIX/ACL hérités d’une ancienne configuration) qui diffèrent des autres partages.
Paramètres SMB (version minimale/maximale, NTLMv2) non alignés ou guest access désactivé alors que le partage l’exigeait.
Résolution de noms (NetBIOS/DNS) incohérente : le nom \\NAS pointe vers une autre IP que celle du serveur Samba attendu.
Filtrage local (pare‑feu/antivirus) qui bloque ou intercepte la négociation SMB avant l’authentification.

Plan d’action rapide (résumé)

Étape	Action à entreprendre	Pourquoi / comment faire ?
1	Vérifier les permissions du dossier dans l’interface OMV : droits POSIX + ACL du partage SMB.	Un même dossier peut avoir des droits différents des autres partages. Assurez‑vous que l’utilisateur dispose de lecture/écriture.
2	Créer (ou recréer) un utilisateur OMV portant exactement le même nom et mot de passe que votre compte Windows local.	L’authentification SMB repose d’abord sur la correspondance « nom + mot de passe » (SSO côté Windows).
3	Aligner la version du protocole SMB : • OMV : `min protocol = SMB2`, `max protocol = SMB3`. • Windows 10/11 : SMB 2/3 activé par défaut.	Évite l’incompatibilité (SMB1 est désactivé par Windows depuis 2017).
4	Purger le cache d’identifiants Windows : `net use * /delete` puis Gestionnaire d’informations d’identification → supprimer les entrées liées au NAS. Redémarrer.	Empêche Windows de réutiliser un jeton obsolète.
5	Utiliser l’adresse IP (`\\192.168.x.x\Backup`) au lieu du nom NetBIOS.	Écarte un problème de résolution de noms (DNS/WINS).
6	Contrôler pare‑feu et antivirus Windows : autoriser « Partage de fichiers et d’imprimantes (SMB‑In) » sur le profil réseau privé.	Un blocage local peut refuser la connexion avant l’authentification.
7	Mettre à jour OMV ou au minimum le paquet `samba`.	Des correctifs peuvent résoudre des régressions d’authentification.
8	Réinitialiser les ACL du dossier, puis réappliquer les droits dans OMV.	Nettoie d’éventuels droits hérités ou corrompus.
9	Activer la journalisation Samba (`log level = 2`) et inspecter les journaux.	Permet d’identifier précisément la cause (NTLM, mappage UID/GID, etc.).

Tutoriel détaillé pas‑à‑pas

Vérifier les permissions dans OMV (POSIX + ACL)

Dans OMV : Accès partagé → Dossiers partagés → sélectionnez Backup → Privilèges. Accordez Lecture/Écriture à l’utilisateur concerné ou au groupe (ex. users).
Onglet ACL : vérifiez qu’aucune entrée Deny ne cible votre utilisateur/groupe. L’héritage doit être cohérent (cocher « appliquer récursivement » si nécessaire).
Côté système (via SSH) : sudo getfacl /srv/dev-disk-by-.../Backup ls -ld /srv/dev-disk-by-.../Backup Les droits attendus pour un partage privé : 770 (ou 750) avec propriétaire/groupe corrects.

Créer/aligner l’utilisateur sur OMV

Deux approches fonctionnent :

Alignement SSO : créer sur OMV un utilisateur strictement identique (même orthographe et mot de passe) à votre session Windows locale. Windows présentera automatiquement ces identifiants au NAS.
Compte dédié (recommandé pour les sauvegardes) : ex. backup. Dans ce cas, connectez‑vous explicitement avec net use (voir plus bas). Vous gagnez en traçabilité et pouvez limiter les droits à ce seul dossier.

Après création/modification, forcez la prise en compte :

sudo systemctl restart smbd nmbd
# ou sur les versions plus récentes :
sudo systemctl restart smbd

Aligner SMB 2/3 des deux côtés

Dans OMV : Services → SMB/CIFS → Paramètres :
- Version minimale : SMB2
- Version maximale : SMB3
- Options supplémentaires (facultatif) : client min protocol = SMB2 server min protocol = SMB2 client max protocol = SMB3 server max protocol = SMB3
Dans Windows, vérifiez la négociation réelle : PowerShell> Get-SmbConnection | Format-Table -Auto La colonne Dialect doit afficher 3.1.1 (ou 3.x) vers le NAS.

Purger le cache d’identifiants et les mappings réseau sous Windows

Fermez toutes les fenêtres de l’Explorateur.
Ouvrez Invite de commandes (admin de préférence) et exécutez : net use * /delete /y klist purge
Ouvrez le Gestionnaire d’informations d’identification (Panneau de configuration → Comptes d’utilisateurs) puis supprimez toute entrée liée à NAS ou à son IP (Informations d’identification Windows).
Redémarrez Windows.
Testez une connexion explicite (remplacez par vos valeurs) : net use \\192.168.1.20\Backup /user:backup ******** /persistent:no Utilisez au besoin un préfixe de domaine de travail : /user:WORKGROUP\backup ou /user:NAS\backup.

Écarter un problème de nom NetBIOS/DNS

Tentez d’ouvrir \\192.168.1.20\Backup. Si ça fonctionne à l’IP et pas au nom, le souci est la résolution. Pour stabiliser les tests :

Videz la résolution NetBIOS : nbtstat -R
Videz le cache DNS : ipconfig /flushdns
Vérifiez l’IP du NAS répondue par ping NAS (doit correspondre).

Vérifier pare‑feu et antivirus

Dans « Pare‑feu Windows Defender avec fonctions avancées de sécurité », assurez‑vous que la règle Partage de fichiers et d’imprimantes (SMB‑In) est Autorisée pour le profil Privé. Certains antivirus ajoutent une « protection des documents » qui bloque SMB : créez une exception pour l’IP du NAS si nécessaire.

Mettre à jour OMV et Samba

Une mise à jour corrige souvent des régressions d’authentification ou des soucis de négociation dialecte/chiffrement.

sudo omv-upgrade
# ou, sur base Debian :
sudo apt update &amp;&amp; sudo apt install --only-upgrade samba
sudo systemctl restart smbd

Réinitialiser proprement les ACL du dossier Backup

Si seul Backup pose problème, suspectez un héritage ACL atypique. Procédez ainsi :

# 1) Sauvegarde des ACL actuelles (optionnelle)
sudo getfacl -R /srv/dev-disk-by-.../Backup &gt; /root/backup.acl

# 2) Purge des ACL étendues et réapplication POSIX

sudo setfacl -bR /srv/dev-disk-by-.../Backup
sudo chown -R backup:users /srv/dev-disk-by-.../Backup
sudo chmod -R 770 /srv/dev-disk-by-.../Backup

# 3) Dans OMV : réappliquez les privilèges/ACL attendus via l’interface

Après cela, redémarrez Samba et testez à nouveau depuis Windows.

Activer la journalisation Samba et lire les journaux

Dans Services → SMB/CIFS → Paramètres, ajoutez dans Options supplémentaires :

log level = 2

Redémarrez Samba puis reproduisez l’échec depuis Windows. Côté NAS :

sudo tail -f /var/log/samba/log.smbd
sudo tail -f /var/log/samba/log.&lt;IP_client&gt;

Exemples d’indices utiles :

NT_STATUS_LOGON_FAILURE : identifiants incorrects ou compte inexistant.
NT_STATUS_ACCESS_DENIED : authentifié mais bloqué par les droits sur le partage ou le système de fichiers.
map access denied / permission denied sur le path : problème POSIX/ACL.
Dialecte SMB1 vu dans les logs : forcer min protocol = SMB2, et vérifier la pile SMB Windows.

Vérifications avancées

Sanity check de la configuration Samba

testparm -s
pdbedit -L
smbstatus

testparm -s doit afficher une section [Backup] propre, par exemple :

[Backup]
  path = /srv/dev-disk-by-.../Backup
  browseable = yes
  read only = no
  create mask = 0660
  directory mask = 0770
  force group = users
  valid users = @users backup

Évitez de laisser guest ok = yes sur un dossier de sauvegarde sensible. Privilégiez une liste blanche (valid users) et un compte dédié (backup).

Diagnostics utiles côté Windows

# Liste des connexions SMB actives et dialectes
PowerShell> Get-SmbConnection

# Mappings réseau (lecteurs mappés)

PowerShell> Get-SmbMapping

# Suppression d’un mapping récalcitrant

PowerShell> Remove-SmbMapping -RemotePath \NAS\Backup -Force

# Test de port SMB (445/TCP)

PowerShell> Test-NetConnection -ComputerName 192.168.1.20 -Port 445

# Forcer une connexion explicite avec domaine de travail

cmd> net use \NAS\Backup /user:WORKGROUP\backup ******** /persistent:no

Cas particuliers et pièges

Compte Microsoft (adresse e‑mail) vs compte local : si vous utilisez un compte Microsoft dans Windows, l’alignement SSO n’est pas pertinent. Utilisez un compte OMV dédié et connectez‑vous avec net use.
Mot de passe vide côté Windows : souvent bloqué par Samba. Donnez un mot de passe non vide aux comptes concernés.
Nom d’hôte contenant des caractères spéciaux : préférez l’IP pour tester. Renommez proprement l’hôte si besoin (Paramètres réseau d’OMV).
Heure système fortement décalée entre PC et NAS : alignez via NTP (un écart massif peut perturber l’authentification).
OffLine Files / Fichiers hors connexion (CSC) activés : ils peuvent conserver des métadonnées obsolètes. Désactivez temporairement dans Centre de synchronisation.

Procédures de secours pour récupérer vos données

Si la reprise d’accès SMB doit attendre, activez de manière temporaire un service alternatif :

SFTP/SSH : activez SSH dans OMV, créez l’utilisateur, puis utilisez un client SFTP pour rapatrier les fichiers.
rsync : côté NAS ou côté PC (via WSL), synchronisez le dossier Backup vers un disque USB.

Une fois la copie terminée, désactivez les services non indispensables et revenez à SMB.

Matrice de décision (où chercher la cause ?)

Symptôme	Piste prioritaire	Action
Autres partages OK, seul `Backup` KO	ACL/droits du dossier	Vérifier Privilèges & ACL OMV, `getfacl`, réappliquer `chmod/chown`
Connexion OK à l’IP, KO au nom	Résolution DNS/NetBIOS	Utiliser IP, purger caches, corriger nom d’hôte
Mot de passe demandé en boucle	Cache d’identifiants	`net use * /delete`, Credential Manager, redémarrer
Erreur immédiate « Access is denied »	Permissions / `valid users`	Vérifier la section `[Backup]` de Samba, journal `NT_STATUS_ACCESS_DENIED`
Impossible de joindre le partage	Pare‑feu ou port 445 bloqué	`Test-NetConnection`, règle SMB‑In, antivirus

Exemple de configuration robuste pour un partage « Backup »

[Backup]
  path = /srv/dev-disk-by-.../Backup
  browseable = yes
  read only = no
  create mask = 0660
  directory mask = 0770
  force group = users
  valid users = backup @backup
  write list = backup
  veto files = /lost+found/
  inherit permissions = yes
  inherit acls = yes
  ea support = yes
  vfs objects = acl_xattr

Associez une stratégie simple côté système : propriétaire backup, groupe users, chmod 770, ACL minimales. Conservez un compte dédié uniquement pour la sauvegarde.

Check‑list de validation

Depuis Windows :
- net use \\NAS\Backup /user:backup renvoie « La commande s’est terminée correctement. »
- Get-SmbConnection affiche Dialect 3.x et le UserName attendu.
- Lecture/écriture d’un fichier test (copy, del) réussies.
Depuis OMV :
- testparm -s ne signale aucune erreur.
- Logs Samba sans NT_STATUS_ACCESS_DENIED ni LOGON_FAILURE lors des essais.
- Droits POSIX/ACL conformes (770, propriétaire/groupe corrects).

Prévention et bonnes pratiques

Comptes dédiés pour chaque usage (ex. backup, media), avec droits minimaux.
Éviter SMB1 : laissez min protocol = SMB2, max protocol = SMB3.
Documenter les paramètres clés (utilisateurs, groupes, ACL, masques) et conserver une capture de testparm -s.
Double sauvegarde : ajoutez un second support (USB, cloud) pour ne pas dépendre d’un seul NAS.
Mises à jour régulières d’OMV et de Windows, en vérifiant les notes liées à Samba.

FAQ rapide

Faut‑il que le nom d’utilisateur Windows soit identique à celui d’OMV ?

Non, ce n’est pas obligatoire. Mais si les noms/mots de passe sont identiques, Windows utilisera le SSO et vous éviterez les invites. Sinon, connectez‑vous explicitement avec net use ... /user:... ou mappez un lecteur réseau en spécifiant l’utilisateur.

Pourquoi les autres partages du NAS restent accessibles ?

Ils peuvent avoir des ACL plus permissives (ex. guest ok), un valid users différent, ou un héritage POSIX correct. Le dossier Backup a souvent une politique plus restrictive.

Dois‑je activer NTLMv1 ou SMB1 pour « faire marcher » ?

Non. Évitez SMB1 et NTLMv1 qui sont obsolètes et vulnérables. Restez en SMB2/3 avec NTLMv2, c’est compatible Windows 10/11 et OMV 5.

Peut‑on forcer l’accès via un seul compte « backup » ?

Oui. Déclarez valid users = backup, positionnez force group, mettez propriétaire/groupe cohérents et des masques de création stricts (0660/0770).

Conclusion

Le refus d’accès à \\NAS\Backup après une réinstallation de Windows provient presque toujours d’un mauvais alignement identité/permissions ou d’un cache Windows récalcitrant. En vérifiant méthodiquement ACL et paramètres SMB sur OMV, en purgeant les identifiants et en testant à l’IP avec un compte dédié, vous rétablirez un accès fiable sans sacrifier la sécurité.

Annexe : bloc mémo des commandes utiles

Contexte	Commande	But
Windows (CMD)	`net use * /delete /y`	Supprimer toutes les connexions SMB mappées/cachées
Windows (PowerShell)	`Get-SmbConnection`	Voir les connexions SMB et le dialecte négocié
Windows (PowerShell)	`Test-NetConnection -ComputerName <IP NAS> -Port 445`	Tester l’accessibilité du port SMB
OMV	`testparm -s`	Valider la configuration Samba
OMV	`smbstatus`	Voir les sessions/fichiers ouverts
OMV	`getfacl /srv/.../Backup`	Inspecter les ACL POSIX
OMV	`setfacl -bR /srv/.../Backup`	Effacer les ACL étendues
OMV	`systemctl restart smbd`	Redémarrer Samba après modification

Notes complémentaires utiles

Les comptes admin et root d’OMV sont désactivés par défaut sur les partages SMB ; utilisez un compte utilisateur normal.
Si vous aviez jadis autorisé des mots de passe vides côté Windows (ou modifié via secpol.msc), revenez aux valeurs par défaut.
En cas d’urgence, activez temporairement FTP/SFTP ou rsync pour copier les données, puis revenez à un partage SMB sain.
Pensez à automatiser vos sauvegardes avec un second support (disque USB, cloud, etc.) pour éviter de dépendre d’un seul NAS.