Sur Windows 10, l’erreur intermittente « you don’t have permission to modify files in this network location » au moment d’enregistrer sur un lecteur réseau SMB a plusieurs causes possibles. Voici un guide opérationnel, concret et reproductible pour trouver l’origine et corriger durablement le problème.
Contexte et symptômes
Un poste Windows 10 relié en Ethernet à votre réseau enregistre parfois des fichiers sur un partage SMB, mais échoue de manière aléatoire avec un message d’autorisation. Une seconde tentative fonctionne. Le symptôme se manifeste dans plusieurs applications (imprimante PDF, export CSV, éditeurs) et ne touche aucun autre utilisateur. Ce schéma indique généralement un incident transitoire côté client, serveur ou réseau, plutôt qu’un refus d’accès « dur ».
Ce que signifie réellement le message
Le message « you don’t have permission to modify files in this network location » n’implique pas forcément un problème de droits. C’est souvent la traduction utilisateur d’un échec SMB au moment d’ouvrir le fichier en écriture (ou de le renommer à la fin d’un enregistrement temp → final). Des facteurs comme un lock opportuniste (oplock) qui expire, un antivirus qui retarde l’accès, une latence soudainement élevée ou un cache hors‑connexion en état incohérent peuvent déclencher une erreur d’accès « fantôme ».
Tableau de diagnostic et actions
| Axe de diagnostic | Mesures principales | Remarques utiles |
|---|---|---|
| Profil utilisateur corrompu | 1. Créer un compte local administrateur :net user NouveauUser * /add net localgroup administrators NouveauUser /add 2. Tester l’enregistrement réseau sous ce compte. Si le problème disparaît, migrer les données de l’ancien profil vers le nouveau (« Copier les fichiers vers le nouveau profil » côté Microsoft). | La corruption de profil est fréquente après des mises à jour majeures ou un espace disque insuffisant. |
| Permissions NTFS / partage | Vérifier que l’utilisateur dispose des droits Contrôle total (ou au moins Modification) à la fois sur le partage réseau et sur le système de fichiers NTFS. | Un écart entre droits NTFS et droits de partage peut provoquer des échecs sporadiques, surtout si un processus de fond réinitialise les ACL. |
| Caching & fichiers hors‑connexion (Offline Files) | Désactiver temporairement la mise en cache SMB : Panneau de configuration → Centre de synchronisation → Gérer les fichiers hors connexion → Désactiver. | Des déconnexions rapides du réseau ou un cache saturé déclenchent parfois une erreur d’autorisation fantôme. |
| Opportunistic Locking / Oplocks | Sur le serveur de fichiers, tester la désactivation des oplocks ou de la mise en cache de dossier (paramètres SMB) pour le dossier concerné. | Les verrous opportunistes peuvent abandonner une requête quand la latence augmente, engendrant un refus d’accès. |
| Antivirus / EDR | Consulter les journaux de sécurité et, si possible, exclure temporairement le chemin réseau de l’analyse en temps réel pour tester l’impact. | Certains agents bloquent brièvement la modification d’un fichier pendant l’analyse, générant une erreur d’accès. |
| Fiabilité du réseau | Mettre à jour le pilote NIC et le firmware du switch si nécessaire. Tester la latence :ping -n 200 <serveur>Des pertes de paquets ou des variations > 10 ms peuvent déclencher le message. | Même câblé, un duplex/vitesse négocié à tort ou un câble défectueux suffit à provoquer un rejet momentané. |
| Journaux d’événements | Observateur d’événements → Journaux Windows → Système et Sécurité. Filtrer les ID = 30805, 30904 (SMBClient) ou 4656/4663 (Audit de fichiers). | Ces entrées précisent souvent la cause (timeout, verrou bloqué, service tiers). |
Plan d’action recommandé
- Tester avec un nouveau profil : rapide à mettre en place, permet d’isoler immédiatement la piste « profil corrompu ».
- Valider les droits NTFS/partage via la console « Partage avancé » et
icacls. - Observer hors‑connexion/antivirus : désactiver temporairement l’option et l’agent, un poste à la fois.
- Analyser les journaux SMB pour confirmer ou infirmer un problème réseau/lock.
- Si le problème persiste : envisager la désactivation des oplocks pour le dossier ou la mise à jour des pilotes réseau.
Vérifications rapides côté client
- Espace disque et intégrité du profil : au moins 10 % libres sur
%SystemDrive%et sur le profil (%USERPROFILE%). Vérifiez l’absence d’erreurs disque (chkdskplanifié). - Cartes réseau : dans Gestionnaire de périphériques → carte Ethernet → onglet Gestion de l’alimentation, décochez « Autoriser l’ordinateur à éteindre ce périphérique pour économiser de l’énergie » pour le test.
- Sessions SMB actives :
Get-SmbConnection net useS’il existe plusieurs connexions vers le même serveur avec des identités différentes, supprimez et remappez :net use * /delete /y net use Z: \\serveur\partage /persistent:yes - Gestionnaire d’informations d’identification : purgez les entrées obsolètes (control.exe keymgr.dll ou
cmdkey /listpuiscmdkey /delete). - Horloge et Kerberos : un décalage d’horloge > 5 minutes casse l’auth intermittente. Vérifier :
w32tm /query /status klist purge
Validation des droits avec précision
Les droits se combinent entre le partage et le système de fichiers. L’accès effectif est le plus restrictif des deux. Procédez ainsi :
- Sur le serveur (via une session admin), listez les autorisations de partage :
Get-SmbShareAccess -Name "PARTAGE" - Sur le dossier NTFS, exportez les ACL :
icacls D:\Données\Equipe /save C:\temp\acl.txt /t /c - Depuis le poste affecté, testez la création/renommage via PowerShell pour isoler l’application :
$p="\\serveur\partage\test-perms" ni "$p\_tmp.txt" -ItemType File -Force ri "$p\_tmp.txt" -ForceSi ce test réussit systématiquement alors que l’application échoue parfois, suspectez un lock ou un filtre (AV/EDR).
Hors‑connexion et caches SMB
Le client SMB maintient plusieurs caches (métadonnées, résultats « fichier introuvable », etc.). Un état incohérent peut provoquer un déni d’accès temporaire.
- Désactiver les fichiers hors‑connexion (test) : Centre de synchronisation → Gérer les fichiers hors connexion → Désactiver → redémarrage.
- Réinitialiser les caches côté client (test court, à rétablir ensuite) :
Get-SmbClientConfiguration Set-SmbClientConfiguration -DirectoryCacheLifetime 0 -FileInfoCacheLifetime 0 -FileNotFoundCacheLifetime 0 -Confirm:$false # ...tester... Set-SmbClientConfiguration -DirectoryCacheLifetime 10 -FileInfoCacheLifetime 10 -FileNotFoundCacheLifetime 10 -Confirm:$false
Oplocks et leasing SMB
Les oplocks (ou « leasing SMB ») améliorent les performances en permettant au client de mettre en cache des opérations. En cas de latence ou d’accès concurrents, ils peuvent provoquer un abandon de l’opération qui se traduit côté application par un Access Denied intermittent.
- Test côté serveur (dossier critique uniquement, et temporaire) : désactivez la mise en cache au niveau du partage.
Set-SmbShare -Name "PARTAGE" -CachingMode NoneSi le problème disparaît, envisagez un réglage fin (par dossier) plutôt qu’une désactivation globale. - Sur des applications sensibles (bases Access, fichiers CAD), préférez un dossier sans caching et des enregistrements atomiques.
Antivirus et EDR
Les solutions AV/EDR inspectent les fichiers réseau. Selon la charge ou la politique, elles peuvent verrouiller temporairement le fichier le temps d’une analyse, ce qui déclenche l’erreur côté application.
- Désactiver l’analyse en temps réel uniquement pour le partage cible (exclusion UNC ou IP) le temps d’un test contrôlé.
- Vérifier les journaux de l’agent au moment exact de l’échec : un événement « quarantaine », « analyse retardée » ou « scan on write » conforte l’hypothèse.
- Mettre à jour l’agent et affiner la politique (exclure les extensions temporaires créées par l’application :
.tmp,.part, etc.).
Test de stabilité réseau
Une micro‑coupure suffit à casser une transaction SMB en écriture. Mesurez la stabilité plutôt que le débit :
ping -n 200 <serveur> # pertes ou jitter > 10 ms = suspect
pathping <serveur> # identifie un saut instable
tracert <serveur>- NIC : mettez à jour le pilote, forcez le débit/duplex si nécessaire (évitez l’auto‑négociation douteuse).
- Switch : firmware, erreurs de port, tempêtes de broadcast.
- QoS : vérifiez que SMB (ports 445) n’est pas priorisé à tort vers le bas.
Journaux à collecter pour prouver la cause
Corrélez l’horodatage de l’échec applicatif avec les journaux suivants :
- Microsoft‑Windows‑SMBClient : Connectivity, Security (ID typiques : 30804/30805/30904).
- Sécurité : 4656 (Handle requested), 4663 (Access attempt), avec l’ObjectName pointant sur le chemin UNC.
- Système : avertissements du pilote réseau, NLA, Netlogon.
Extraction ciblée en PowerShell :
# 15 dernières minutes d'événements SMBClient
wevtutil qe Microsoft-Windows-SMBClient/Connectivity /q:"*[System[TimeCreated[timediff(@SystemTime) <= 900000]]]" /f:text
# Audits d'accès au chemin concerné (si l'audit est activé sur le dossier)
wevtutil qe Security /q:"*[System[(EventID=4663 or EventID=4656)] and EventData[Data[@Name='ObjectName'] and (Data='\serveur\partage\chemin\fichier.ext')]]" /f:textProcédure complète pas à pas
- Reproduire : notez l’heure exacte (à la seconde) et l’application utilisée. Essayez une seconde fois pour confirmer que la répétition fonctionne.
- Changer d’identité utilisateur : créez NouveauUser (voir commandes plus haut) et refaites le test. Si tout est OK, planifiez la migration de profil (copie de
C:\Users\AncienUser→C:\Users\NouveauUsersansNTUSER.DATniAppData\Local\Temp). - Valider droits :
icaclscôté NTFS +Get-SmbShareAccesscôté partage. Harmonisez les deux (évitez les Deny hérités). - Désactiver Offline Files pour le test, puis redémarrage. Vérifier si l’erreur disparaît.
- Exclure temporairement le dossier côté AV/EDR et retester.
- Contrôler la latence pendant une tentative d’enregistrement ; collecter
ping -ten parallèle. - Oplocks : mettez
-CachingMode Nonesur le partage du dossier problématique. Si amélioration, conserver ce réglage pour ce dossier sensible. - Mettre à jour : pilote NIC, pile SMB (Windows Update), firmware du switch. Redémarrer proprement le poste et le serveur si possible.
Commandes utiles prêtes à l’emploi
Inventaire rapide
whoami /user
whoami /groups
systeminfo | findstr /i "OS Name OS Version"
Get-SmbConnection | ft -a
Get-SmbClientConfiguration | flContrôle des mappages
net use
net use Z: \\serveur\partage /user:DOMAINE\Utilisateur /persistent:yesACL côté dossier
icacls "\\serveur\partage\chemin" /t /cRemise à zéro caches SMB (test)
Set-SmbClientConfiguration -DirectoryCacheLifetime 0 -FileInfoCacheLifetime 0 -FileNotFoundCacheLifetime 0 -Confirm:$falseHeure et tickets
w32tm /query /status
klist
klist purgeCas particuliers à ne pas oublier
- DFS Namespace : si vous accédez via un espace de noms DFS, essayez le chemin UNC direct vers le serveur de fichiers pour voir si le problème vient d’un lien DFS ou d’un serveur particulier.
- Group Policy Preferences (GPP) Drive Mapping : un paramètre « Toujours mettre à jour » peut provoquer une reconnection au mauvais moment. Testez un mappage statique
net usepour isoler. - Conflits d’identités : des sessions simultanées vers le même serveur avec des comptes différents peuvent être refusées par SMB. Nettoyez
net use * /deletepuis remappez. - Temps de nommage de fichier : certaines applis écrivent d’abord
~tmppuis renomme en final. Les refus de rename sont typiques d’un lock concurrent (outil de prévisualisation, indexation, EDR).
Check‑list de résolution durable
| Élément | Action | Statut cible |
|---|---|---|
| Profil utilisateur | Tester sous NouveauUser, migrer si confirmé | OK ou migré |
| Droits NTFS/partage | Aligner Modification sur les deux couches, auditer les Deny | Alignés |
| Offline Files | Désactiver ou vider le cache, ne l’activer que si nécessaire | Désactivé (test) / Ajusté |
| Oplocks | -CachingMode None sur le dossier sensible | Réglé par dossier |
| AV/EDR | Exclusions sur le chemin UNC et extensions temporaires | Exclusions en place |
| Réseau | Pilotes NIC / firmware switch à jour, jitter <= 10 ms | Stabilité prouvée |
| Journaux | Événements SMB corrélés, capture conservée | Évidences collectées |
Exemple de scénario résolu
Un utilisateur Windows 10 se plaint d’un refus d’accès aléatoire en sauvegardant des PDF sur \\FS01\Comptabilité. Sous un profil test, tout fonctionne. Les journaux SMBClient montrent des timeouts corrélés aux scans de l’agent EDR. Après exclusion du dossier et désactivation du caching sur ce partage particulier, plus aucune alerte. Le profil utilisateur a ensuite été migré pour repartir sur une base saine.
FAQ express
Pourquoi la seconde tentative réussit‑elle ?
Parce que la tentative initiale échoue pendant une fenêtre transitoire (scan, lock, latence). Quelques secondes plus tard, le lock est levé ou le cache est cohérent, et l’ouverture en écriture aboutit.
Dois‑je désactiver définitivement les oplocks ?
Non. Désactivez‑les uniquement sur un dossier/partage sensible si vous avez prouvé que c’est le facteur causal. Les conserver sur le reste du stockage améliore les performances.
Les droits sont corrects, pourtant j’ai l’erreur.
Vérifiez les Deny hérités, les sessions SMB concurrentes avec d’autres identités, et les filtres AV/EDR. Contrôlez aussi l’horloge et la stabilité réseau.
Résumé opérationnel
Commencez par isoler le profil, vérifiez finement les droits NTFS/partage, neutralisez temporairement Offline Files et les filtres AV/EDR, puis mesurez la stabilité réseau. Appuyez‑vous sur les journaux SMB pour lier l’échec à une cause tangible. Si nécessaire, réglez les oplocks par dossier. Cette séquence couvre l’écrasante majorité des cas où Windows 10 affiche « you don’t have permission to modify files in this network location » lors d’un enregistrement sur un lecteur réseau, et restaure une sauvegarde fluide et prévisible.
Annexe : script de collecte rapide (client)
Exécutez en PowerShell en tant qu’administrateur puis joignez le ZIP à votre ticket.
$out = "$env:PUBLIC\SMB-Diag-$((Get-Date).ToString('yyyyMMdd-HHmmss'))"
New-Item -ItemType Directory -Path $out | Out-Null
'==== SmbConnection ====' | Out-File "$out\diag.txt" -Encoding UTF8
Get-SmbConnection | Format-List * | Out-File "$out\diag.txt" -Append -Encoding UTF8
'==== SmbClientConfiguration ====' | Out-File "$out\diag.txt" -Append -Encoding UTF8
Get-SmbClientConfiguration | Format-List * | Out-File "$out\diag.txt" -Append -Encoding UTF8
'==== Net Use ====' | Out-File "$out\diag.txt" -Append -Encoding UTF8
cmd /c "net use" | Out-File "$out\diag.txt" -Append -Encoding UTF8
'==== Ping 200 ====' | Out-File "$out\diag.txt" -Append -Encoding UTF8
cmd /c "ping -n 200 serveur" | Out-File "$out\diag.txt" -Append -Encoding UTF8
'==== Time & Kerberos ====' | Out-File "$out\diag.txt" -Append -Encoding UTF8
w32tm /query /status | Out-File "$out\diag.txt" -Append -Encoding UTF8
klist | Out-File "$out\diag.txt" -Append -Encoding UTF8
'==== SMBClient last 15 min ====' | Out-File "$out\diag.txt" -Append -Encoding UTF8
wevtutil qe Microsoft-Windows-SMBClient/Connectivity /q:"*[System[TimeCreated[timediff(@SystemTime) <= 900000]]]" /f:text | Out-File "$out\diag.txt" -Append -Encoding UTF8
Compress-Archive -Path "$out\*" -DestinationPath "$out.zip" -Force
Write-Host "Fini : $out.zip"Conclusion : en abordant méthodiquement les couches profil → droits → cache/AV → réseau → journaux → paramètres SMB, vous transformez une erreur sporadique et frustrante en un incident compris, documenté et résolu. Conservez vos réglages de test (exclusions, désactivation de caches) seulement si la corrélation avec la résolution est prouvée, sinon revenez à la configuration standard.