ROMFASTSQL/docs/handoff-smb-vm303-roacentral.md

Handoff — SMB imposibil între VM 303 și VM 201 (SID de mașină duplicat)

Data: 2026-08-10, seara Stare: cauză stabilită prin probe; reparația finală (sysprep) NU e făcută, așteaptă decizia utilizatorului.

Simptom raportat

De pe VM 303 (10.0.20.145) nu se poate accesa \\10.0.20.122\temp; „user sau parolă incorecte" chiar cu credențiale corecte. Identic și în sens invers, de pe .122 către \\10.0.20.145\Temp.

Cauza reală

Cele două mașini au același SID de mașină: S-1-5-21-1850128657-3079265004-705332634

VM 303 e o clonă (prin template-ul VM 300 Win11-Template) a instalării de pe VM 201, pornită fără sysprep /generalize. NTLM între două mașini cu SID de mașină identic eșuează: parola e validată corect, apoi logon-ul e respins.

Inițial ambele se numeau și ROACENTRAL — asta a fost reparată (vezi mai jos), dar nu a fost suficientă.

Semnătura în log (Security, event 4625, pe mașina țintă)

SubStatus	Semnificație
0xc000006a	parola chiar e greșită (verificarea a ajuns la SAM)
0x0	parola e CORECTĂ, logon respins ulterior — semnătura problemei

Deci sub=0x0 = simptomul; sub=0xc000006a = doar o parolă greșită banală.

Lanțul de probe (toate rulate, nu deduse)

1. VM-303 → .122 eșuează; .122 → VM-303 eșuează. Simetric.
2. Cont nou smbtest pe VM-303, parolă pusă de noi, RID 1002 (se ciocnea cu roaupdate de pe .122) → eșec, eroare 86.
3. Cont nou smbshare pe VM-303, RID 1005 (fără nicio coliziune de RID) → eșec. ⇒ nu e coliziunea de RID a contului, ci SID-ul de mașină.
4. De pe LENOVO-AIO-BIRO (stație terță, alt SID) către \\10.0.20.145\Temp, cu exact același cont și aceeași parolă → SUCCES. ⇒ serverul SMB de pe VM-303 e sănătos; problema e a perechii de cloni.

Exclus prin verificare, nu prin presupunere

Parole goale (LimitBlankPasswordUse=1, dar niciuna nu e goală); expirare parolă (Password expires: Never); SMB1/semnare/criptare (identice pe ambele: SMB2/3, signing required, RejectUnencryptedAccess=True); politici RestrictNTLM (nesetate); SeDenyNetworkLogonRight (doar Guest); blocare cont (Account active: Yes); firewall (445 deschis în ambele sensuri); permisiuni share/NTFS pe .122\temp (Everyone: Full, Authenticated Users: Modify); prefixul de domeniu din user (ROACENTRAL\, VM-303\, 10.0.20.122\ — toate se comportă la fel).

Ce s-a modificat deja

Pe VM 303 (10.0.20.145) — singura mașină atinsă:

• Snapshot Proxmox pre-rename creat la 22:19 (încă existent, nu a fost șters).
• Redenumit ROACENTRAL → VM-303 (Rename-Computer), repornit. Numele cu spațiu cerut inițial („VM 303") nu e valid în Windows.
• AutoAdminLogon setat pe 0 (era 1, cu DefaultUserName=romfast și fără parolă stocată validă — login automat rupt).
• Conturi de test smbtest, smbshare, zzfill1, zzfill2 — create pentru probe și șterse. Verificat: au rămas doar Administrator, DefaultAccount, Guest, romfast, WDAGUtilityAccount.

Pe VM 201 (10.0.20.122) — NIMIC modificat. Doar citiri și net use de test, ale căror mapări au fost șterse.

Ce NU e făcut — VM 303 rămâne nereparat (decizie a utilizatorului)

Utilizatorul a cerut explicit nicio modificare suplimentară pe VM 303. Deci VM 303 are în continuare SID-ul duplicat și SMB către/dinspre VM 201 nu va funcționa.

Ce rămâne, dacă se dorește reparat mai târziu:

1. sysprep /generalize /oobe pe VM 303 — singura metodă suportată de Microsoft (vezi capcanele de mai jos, sunt aceleași).
2. Reconstruire VM 303 din template-ul curat VM 310.

Ocolire funcțională, fără sysprep: VM 201 are OpenSSH pe portul 22 (verificat deschis) — transfer de fișiere prin SFTP/SCP, care nu folosește NTLM:

scp fisier.txt romfast@10.0.20.122:/C:/temp/

✅ REPARAT — template curat pentru viitor: VM 310

Cauza la sursă: template-ul VM 300 Win11-Template nu era sysprep-uit — verificat, purta SID-ul S-1-5-21-1850128657-3079265004-705332634, identic cu VM 201. Orice clonă din el moștenea numele ROACENTRAL și acel SID.

VM 300 nu poate fi reparat în loc: e template (read-only) și VM 303 e linked clone din el (origin: rpool/data/base-300-disk-0@__base__). Modificarea bazei ar distruge VM 303.

Soluția aplicată: clonă completă 300 → VM 310, sysprep acolo, conversie în template.

	VM 300 (vechi)	VM 310 (nou)
Nume la clonare	ROACENTRAL (fix)	DESKTOP-xxxxxxx (aleator, prin OOBE)
SID de mașină	fix, al lui VM 201	nou la fiecare clonă
Stare	⛔ nu clona	✅ de folosit

Verificat efectiv, nu presupus: o clonă de probă (VM 311, ștearsă după test) a pornit cu DESKTOP-88DEOL2 și SID S-1-5-21-2704088831-3630746092-3876790623 — complet diferit.

Capcană la sysprep (dacă se repetă operația)

Prima rulare a eșuat. Două lucruri de rezolvat înainte:

1. Reboot CBS în așteptare — HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending. Repornește întâi.
2. Pachete Appx instalate per-utilizator dar neprovizionate — sysprep se oprește cu 0x80073cf2. Log-ul le numește explicit în C:\Windows\System32\Sysprep\Panther\setuperr.log. Aici au fost Microsoft.Winget.Source, Microsoft.StartExperiencesApp, Microsoft.WidgetsPlatformRuntime; scoase cu Remove-AppxPackage -AllUsers.

sysprep /generalize /oobe /shutdown oprește VM-ul doar dacă reușește — dacă mașina rămâne pornită, a eșuat, citește setuperr.log. Nu porni VM-ul după sysprep reușit: prima pornire consumă generalizarea. Convertește direct în template.

Documentație aliniată

proxmox/README.md, proxmox/cluster/README.md, proxmox/vm302-oracle-test/README.md și proxmox/lxc108-oracle/roa-windows-setup/test/clone-vm300.sh (SOURCE_VMID 300 → 310) indică acum template-ul nou și marchează VM 300 ca „nu clona".

VM 300 nu poate fi șters cât timp există VM 303 (linked clone).

⚠️ Verificat și nepericulos (fals alarm ridicat pe parcurs)

Task-ul \tasks xml roa de pe .122 (zilnic 16:00, rulează ca romfast cu LogonType=Password, acțiune D:\ROAUPDATE\TASKS\tasks.exe s xml_roa_auto) părea că se va rupe după schimbarea parolei din 10.08 ora 22:02. Utilizatorul a pus la loc aceeași parolă și a testat task-ul — funcționează. Nu necesită intervenție.

Cum se accesează mașinile (fără parole)

ssh root@10.0.20.201                      # cheie SSH deja acceptată
qm guest exec 303 -- powershell.exe -NoProfile -EncodedCommand <base64-UTF16LE>
qm guest exec 201 -- powershell.exe -NoProfile -EncodedCommand <base64-UTF16LE>

Quoting-ul prin ssh → qm guest exec → cmd.exe rupe argumentele; -EncodedCommand cu base64 UTF-16LE e singura variantă care merge de fiecare dată.

Curățenie rămasă

ssh root@10.0.20.201 "qm delsnapshot 303 pre-rename"   # după ce totul e confirmat