Vous tentez de partager des dossiers entre deux PC Windows 10/11 reliés au même compte Microsoft, mais l’un refuse l’accès (mot de passe jugé incorrect), n’affiche pas toujours l’invite d’authentification et l’iPhone renvoie « rpc struct is bad » en SMB. Voici un guide complet, concret et sûr.
Vue d’ensemble de la situation
Dans un réseau domestique, les deux PC apparaissent parfois dans l’Explorateur, mais l’accès à l’un d’eux échoue systématiquement depuis l’autre : on vous redemande le mot de passe, l’invite ne s’affiche pas, ou un client iOS (App Fichiers) affiche « rpc struct is bad ». Les deux machines utilisent un compte Microsoft (pas de compte local). Ce comportement est typique d’une combinaison de problèmes : mauvais format d’identifiant, services de découverte inactifs, règles de pare‑feu SMB, identifiants en cache, ou droits Share/NTFS non alignés.
Pourquoi l’authentification SMB échoue (faits essentiels)
- Le PIN/Windows Hello n’est pas un mot de passe réseau : pour SMB, Windows et iOS exigent un vrai mot de passe du compte. Un PIN est local à la machine et ne peut pas être présenté au serveur SMB.
- Format d’utilisateur : pour un compte Microsoft, la forme correcte est souvent
MicrosoftAccount\adresse_email@exemple.com. Saisir seulement l’email peut échouer selon la configuration. - Découverte et publication : si les services Function Discovery & co ne tournent pas, la machine n’est pas « vue » correctement ou refuse la négociation.
- Pare‑feu : les règles File and Printer Sharing (SMB‑In) doivent être actives pour le profil Privé (TCP 445).
- Connexions persistantes et identifiants en cache : un jeton invalide empêche tout nouvel essai correct jusqu’à purge.
- Permissions : un dossier peut être « partagé » (Share) mais refuser l’accès au niveau NTFS (onglet Sécurité) si les deux ne sont pas cohérents.
- iPhone/iPad : l’App Fichiers n’accède pas aux partages administratifs (
C$,D$) et n’aime pas certains réglages SMB avancés (ex. chiffrement imposé). L’erreur « rpc struct is bad » indique souvent une négociation incompatible ou des identifiants non acceptés.
Procédure de réparation pas à pas
Configurer le profil réseau et la découverte
- Sur chaque PC : Paramètres → Réseau & Internet → propriétés de l’adaptateur → définir le réseau en Privé.
- Paramètres → Réseau & Internet → Paramètres de partage avancés :
- Activer Découverte du réseau et Partage de fichiers et d’imprimantes.
- Laisser Partage protégé par mot de passe activé (recommandé).
- Ouvrir
services.mscet régler en Automatique (Démarrage différé) puis démarrer :- Function Discovery Provider Host (
fdPHost) - Function Discovery Resource Publication (
FDResPub) - SSDP Discovery (
SSDPSRV) - UPnP Device Host (
upnphost) - Server (
LanmanServer) et Workstation (LanmanWorkstation)
- Function Discovery Provider Host (
Vérification rapide en PowerShell :
Get-Service FDResPub,fdPHost,SSDPSRV,upnphost,LanmanServer,LanmanWorkstation |
Select-Object Name, Status, StartType
Utiliser des identifiants valides (mot de passe, pas PIN)
Avec un compte Microsoft, la manière la plus fiable de s’authentifier sur le PC cible est :
Nom d’utilisateur : MicrosoftAccount\adresse_email@exemple.com
Mot de passe : <mot de passe du compte Microsoft>
Si cela échoue encore, deux alternatives robustes :
- Saisir directement l’adresse email comme nom d’utilisateur (sans préfixe), mot de passe du compte Microsoft.
- Créer un compte local dédié sur le PC qui héberge le partage (évite toute ambiguïté d’identité).
Créer un compte local dédié et s’y connecter
- Paramètres → Comptes → Famille et autres utilisateurs → Ajouter un utilisateur sans compte Microsoft.
- Nom :
shareuser, définir un mot de passe. - Depuis l’autre PC, se connecter à la ressource avec :
Nom d’utilisateur : NOMDUPC\shareuser Mot de passe : <mot de passe défini>
Création identique en PowerShell (sur le PC serveur) :
$pwd = Read-Host "Mot de passe pour shareuser" -AsSecureString
New-LocalUser -Name "shareuser" -Password $pwd -FullName "Compte de partage"
Add-LocalGroupMember -Group "Users" -Member "shareuser"
Créer le partage et aligner les droits
- Créer un dossier dédié :
C:\Partage(évitez de partagerC:\). - Clic droit → Propriétés → onglet Partage → Partager… → ajouter le compte (MicrosoftAccount ou
shareuser) avec Lecture ou Lecture/Écriture. - Onglet Sécurité (NTFS) : ajouter le même compte avec des droits cohérents (ex. Modification si écriture autorisée au partage). Sans ce double alignement, l’accès échouera malgré un partage « visible ».
En PowerShell :
New-Item -Path "C:\Partage" -ItemType Directory -Force | Out-Null
# Exemple : plein accès pour l'utilisateur local "shareuser"
icacls "C:\Partage" /grant "NOMDUPC\shareuser:(OI)(CI)M" /T
New-SmbShare -Name "Partage" -Path "C:\Partage" -ChangeAccess "NOMDUPC\shareuser"
Autoriser SMB dans le pare‑feu Windows
Ouvrir Pare‑feu Windows Defender → Paramètres avancés → Règles de trafic entrant → activer toutes les entrées File and Printer Sharing (SMB‑In) pour le profil Privé. Si un pare‑feu/antivirus tiers est installé, désactivez‑le brièvement pour tester (et créez ensuite une exception TCP 445).
Test de connectivité depuis le client :
Test-NetConnection -ComputerName PC_CIBLE -Port 445
# ou
Test-NetConnection -ComputerName 192.168.1.50 -Port 445
Purger les sessions SMB et tester “proprement”
Sur le PC client, supprimez toute connexion SMB persistante avant de réessayer :
net use * /delete /y
net use \\PC_CIBLE\IPC$ /user:MicrosoftAccount\adresse_email@exemple.com
# ...saisir le mot de passe quand demandé
# Puis accéder au partage :
start \\PC_CIBLE\Partage
# ou par IP :
start \\192.168.1.50\Partage
Si vous utilisez le compte local dédié :
net use \\PC_CIBLE\IPC$ /user:NOMDUPC\shareuser
Nettoyer les identifiants enregistrés
Ouvrir Gestionnaire d’identifiants (Panneau de configuration) → Identifiants Windows → supprimer toutes les entrées liées à \\PC_CIBLE (ou à l’adresse IP) afin d’éviter la réutilisation de mauvais jetons. Relancez ensuite un test net use (voir ci‑dessus).
Accès depuis iPhone/iPad (App Fichiers → « Se connecter à un serveur »)
- Serveur :
smb://ADRESSE_IP(ex.smb://192.168.1.50) ousmb://NOMDUPC. - Nom d’utilisateur : adresse Microsoft complète ou
NOMDUPC\shareuser. Laisser Domaine vide. - Choisir un partage utilisateur (ex.
Partage), pasC$/D$.
Si « rpc struct is bad » persiste :
- Vérifiez les services de découverte et l’ouverture du port 445 côté PC.
- Assurez‑vous que le partage n’impose pas des paramètres non standard (ex. chiffrement obligatoire). Par défaut, Windows ne l’exige pas ; si vous l’avez forcé, désactivez l’obligation sur ce partage domestique.
- Supprimez la connexion iOS existante (dans Fichiers, section Serveurs), puis recréez‑la.
Diagnostics avancés (précis et actionnables)
Valider l’écoute SMB et la résolution
# Sur le PC serveur
Get-SmbServerConfiguration | Select-Object EncryptData, EnableSMB2Protocol, EnableSMB1Protocol, RequireSecuritySignature
netstat -ano | findstr ":445"
ipconfig /all
- EnableSMB2Protocol doit être True. EnableSMB1Protocol devrait rester False (ne pas activer SMBv1).
- EncryptData devrait être False côté serveur pour un environnement domestique standard, sauf besoin spécifique.
- Si la résolution de noms échoue, testez par IP. Éventuellement vider les caches :
ipconfig /flushdns.
Observer les sessions SMB en direct
# Sur le serveur
Get-SmbSession | Select-Object ClientComputerName, UserName, NumOpens, Dialect
Get-SmbOpenFile | Select-Object ClientComputerName, Path, SessionId
Si aucune session n’apparaît lors d’une tentative, suspectez pare‑feu, format d’utilisateur, ou refus précoce d’authentification.
Journaliser les échecs d’authentification
Observateur d’événements → Journaux Windows → Sécurité : événements 4625 (échec d’ouverture de session) indiquent l’identité rejetée (ex. Utilisateurs anonymes si un invité est tenté) et le processus d’authentification (NTLM). Cela confirme souvent un mauvais format d’utilisateur ou un mot de passe erroné.
Aligner finement Share vs NTFS
Share contrôle l’accès via le réseau ; NTFS contrôle l’accès au système de fichiers. Le plus restrictif gagne. Pour un test court :
# Autoriser temporairement l'accès complet à shareuser (pour valider la chaîne SMB)
icacls "C:\Partage" /grant "NOMDUPC\shareuser:(OI)(CI)F"
Set-SmbShare -Name "Partage" -FullAccess "NOMDUPC\shareuser"
# Une fois validé, revenir à des droits d'usage (Modification plutôt que Total)
Contrôler les options client
Get-SmbClientConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature, EnablePlainTextPassword
- EnablePlainTextPassword doit rester False.
- Ne forcez pas RequireSecuritySignature sauf besoin. Laissez les valeurs par défaut pour maximiser la compatibilité.
Tableaux de référence rapide
Services indispensables à la découverte
| Service | Nom système | Rôle | État recommandé |
|---|---|---|---|
| Function Discovery Provider Host | fdPHost | Découverte des périphériques/réseaux | Automatique (Démarrage différé), Démarré |
| Function Discovery Resource Publication | FDResPub | Publication des partages | Automatique (Démarrage différé), Démarré |
| SSDP Discovery | SSDPSRV | Découverte UPnP | Automatique (Démarrage différé), Démarré |
| UPnP Device Host | upnphost | Hôte UPnP | Automatique (Démarrage différé), Démarré |
| Server | LanmanServer | Service de partage SMB | Automatique, Démarré |
| Workstation | LanmanWorkstation | Client SMB | Automatique, Démarré |
Formats d’utilisateur valides selon le type de compte
| Type de compte | Nom d’utilisateur | Exemple | Remarques |
|---|---|---|---|
| Compte Microsoft | MicrosoftAccount\email | MicrosoftAccount\jean.dupont@outlook.com | Le plus fiable pour SMB |
| Compte Microsoft | Email seul | jean.dupont@outlook.com | Peut suffire selon la machine |
| Compte local | NOMDUPC\utilisateur | PCSALON\shareuser | Très stable en réseau domestique |
| Administratif | Administrateur local | NOMDUPC\Administrateur | Évitez pour un partage quotidien |
Messages d’erreur courants et correctifs
| Symptôme | Cause la plus probable | Correctif rapide |
|---|---|---|
| « Mot de passe incorrect » | Email saisi seul, PIN utilisé, mauvais cache | Utiliser MicrosoftAccount\email, purger net use * /delete, supprimer identifiants Windows |
| Pas d’invite d’authentification | Connexions invitées refusées mais tentées, pare‑feu bloque | Forcer l’utilisateur/mot de passe via net use \\PC\IPC$ /user:..., vérifier SMB‑In |
| « rpc struct is bad » (iOS) | Négociation incompatible, partage admin, identifiants erronés | Utiliser smb://IP, compte valide, éviter C$, tester sans chiffrement imposé |
| On voit le PC mais accès refusé | Droits Share/NTFS non alignés | Donner les mêmes droits au même compte dans les deux onglets |
Différences Share vs NTFS (résumé pratique)
| Aspect | Share | NTFS |
|---|---|---|
| Où | Onglet « Partage » | Onglet « Sécurité » |
| S’applique à | Accès via le réseau | Accès local et réseau |
| Granularité | Lecture / Modification / Contrôle total | Autorisations détaillées (liste, lecture, écriture…) |
| Arbitrage | Le plus restrictif des deux l’emporte | |
Règles pare‑feu Windows à connaître
| Nom | Port | Profil | Doit être |
|---|---|---|---|
| File and Printer Sharing (SMB‑In) | TCP 445 | Privé | Activé |
| File and Printer Sharing (NB‑Session‑In) | TCP 139 | Privé | Optionnel (SMB moderne utilise 445) |
Bonnes pratiques de sécurité (sans compromis inutile)
- Ne pas activer SMBv1 : obsolète et vulnérable. Rien dans ce guide n’exige SMBv1.
- Conserver le partage protégé par mot de passe et utiliser des comptes nominatifs (MicrosoftAccount ou local dédié).
- Éviter les partages administratifs (
C$,D$) pour un usage quotidien et pour les clients iOS. - Synchroniser date/heure des deux PC (NTP). Des dérives importantes perturbent l’authentification.
- Éviter les permissions « Tout le monde » en écriture ; préférez un utilisateur dédié.
Cas particuliers et pièges courants
- Deux PC connectés à des VLAN/Wi‑Fi invités différents : le port 445 peut être isolé. Testez par IP et vérifiez le segment réseau.
- VPN actif : certaines configurations redirigent tout le trafic et bloquent SMB local. Coupez le VPN pour tester.
- Antivirus/pare‑feu tiers : même désactivés, ils peuvent laisser des filtres. Créez une règle explicite pour
Systemsur TCP 445. - Noms de PC identiques ou changés récemment : la résolution de noms peut pointer vers l’ancien hôte. Redémarrez les machines et testez par IP.
- Chiffrement SMB « exigé » sur un partage : l’iPhone peut échouer selon la version. Par défaut, Windows n’impose pas le chiffrement ; laissez‑le désactivé à l’échelle du partage domestique.
- Sessions concurrentes avec des identités différentes vers le même hôte : Windows n’autorise pas plusieurs identités pour le même nom de serveur. Utilisez soit le nom DNS, soit l’IP, mais pas les deux en parallèle pour des comptes différents. Purgez avec
net use * /deleteentre deux essais.
FAQ ciblée
Q : Je saisis bien l’email et le mot de passe, pourquoi « mot de passe incorrect » ?
R : Essayez MicrosoftAccount\email comme nom d’utilisateur. Si l’échec persiste, créez un compte local dédié et testez ; cela élimine les ambiguïtés liées aux identités Microsoft.
Q : L’invite d’authentification n’apparaît pas, j’ai un accès refusé direct.
R : Supprimez les connexions existantes (net use * /delete), effacez les identifiants enregistrés, puis lancez explicitement net use \\PC\IPC$ /user:... pour forcer l’authentification.
Q : iPhone → « rpc struct is bad ».
R : Connectez‑vous à smb://IP (pas un partage admin), utilisez un utilisateur + mot de passe valides, et vérifiez que le serveur n’impose pas des options SMB non standards (chiffrement requis).
Q : Faut‑il activer « Connexions invitées » ?
R : Non. Laissez‑les désactivées. Les invités posent des problèmes de sécurité et d’incompatibilités. Préférez un utilisateur dédié.
Check‑list rapide (à cocher mentalement)
- Réseau Privé + découverte et partage activés.
- Services FDResPub, fdPHost, SSDPSRV, upnphost, LanmanServer, LanmanWorkstation démarrés.
- Dossier dédié partagé ; droits Share + NTFS alignés.
- Connexion avec un mot de passe (MSA
MicrosoftAccount\emailouPC\localuser). - SMB‑In autorisé dans le pare‑feu (profil Privé).
net use * /deletepuis test via\\PC\IPC$et\\PC\Partage.- Identifiants Windows nettoyés.
- iPhone :
smb://IP, bon identifiant, pas de partage administrateur.
Script express PowerShell (optionnel, lecture seule)
Ce script n’altère pas la configuration ; il dresse un état des lieux rapide. Exécutez‑le côté PC serveur.
# Résumé SMB côté serveur
Write-Host "=== Services clefs ==="
Get-Service FDResPub,fdPHost,SSDPSRV,upnphost,LanmanServer,LanmanWorkstation |
Select-Object Name, Status, StartType | Format-Table -AutoSize
Write-Host "\`n=== Pare-feu (port 445) ==="
Test-NetConnection -Port 445 -ComputerName \$env\:COMPUTERNAME |
Select-Object ComputerName, TcpTestSucceeded | Format-Table -AutoSize
Write-Host "\`n=== Configuration SMB Serveur ==="
Get-SmbServerConfiguration | Select-Object EnableSMB2Protocol, EnableSMB1Protocol, EncryptData, RequireSecuritySignature |
Format-List
Write-Host "\`n=== Partages ==="
Get-SmbShare | Where-Object {$\_.Name -ne "IPC\$"} |
Select-Object Name, Path, EncryptData, FolderEnumerationMode | Format-Table -AutoSize Conclusion
La quasi‑totalité des échecs « mot de passe incorrect » et des erreurs iOS « rpc struct is bad » lors d’un partage Windows 10/11 provient d’une authentification mal formée (PIN/Hello au lieu d’un mot de passe, email sans préfixe MicrosoftAccount\), de services de découverte inactifs, d’un pare‑feu qui filtre SMB, d’identifiants en cache ou d’autorisations Share/NTFS désalignées. En appliquant la méthode ci‑dessus — profil réseau privé, services démarrés, compte avec mot de passe (ou compte local dédié), alignement des droits, purge des sessions, test via IPC$, et vérifications ciblées côté iPhone — vous rétablirez un accès fiable et sécurisé, sans recourir à des options obsolètes (SMBv1, invités) ni affaiblir votre posture de sécurité.
Informations complémentaires utiles
- Sur un PC Windows 10 accédant à un Windows 11 (et inversement), les règles SMB sont identiques. Démarrez toujours par un test local : sur le PC serveur, tapez
\\localhost\Partagedans l’Explorateur. Si cela échoue, corrigez d’abord les autorisations avant d’investiguer le réseau. - Après des modifications structurantes (droits, services, pare‑feu), redémarrez les deux machines pour lever tout état résiduel.
- La réinitialisation réseau (Paramètres → Réseau & Internet → Paramètres réseau avancés → Réinitialisation du réseau) est un dernier recours utile en cas d’empilement d’anciens pilotes ou filtres.