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.

✅ REPARAT — VM 303 sysprep-uit în loc, cu programele păstrate

Reparat prin sysprep /generalize /oobe /shutdown /unattend:C:\unattend.xml pe VM 303 însuși, nu prin mutare pe alt VM. Sysprep schimbă identitatea mașinii, nu dezinstalează aplicații — exact ce trebuia.

	Înainte	După
SID mașină	S-1-5-21-1850128657-3079265004-705332634	S-1-5-21-3853882515-1460096973-3208817208
Nume	VM-303	VM-303 (repus manual, vezi mai jos)
IP (DHCP)	10.0.20.145	10.0.20.101 ⚠️

Verificat după reparație:

• Toate 14 programele intacte (Adobe Acrobat, Visual FoxPro 9.0, ROACLIENT 2.2.6.1, TortoiseSVN, Git, Node.js, PowerShell 7, Notepad++, RustDesk, Python Launcher, Edge, VC++ 2005, QEMU guest agent, drivere Virtio).
• Profilul romfast intact — 2944 MB, C:\Users\romfast se rezolvă corect la VM-303\romfast, SID <nou>-1001. Nu a devenit „temporary profile".
• Blocajul SMB a dispărut. Dovada, în log-ul de pe .122:

  22:35:10  de la .145  sub=0x0         <- inainte: parola CORECTA, respinsa structural
  23:36:43  de la .101  sub=0xc000006a  <- dupa: parola pusa gresit, evaluata normal
  

De reținut pentru data viitoare:

• <ComputerName> din unattend.xml nu a fost aplicat (mașina a pornit ca WIN-SN6AFCEVSRR); restul unattend-ului a mers (OOBE trecut automat, fără ecran de creare cont). Redenumit ulterior cu Rename-Computer + repornire.
• Sysprep a readus AutoAdminLogon = 1; a fost pus înapoi pe 0.
• Windows nu era activat nici înainte (LicenseStatus 5), deci nu s-a pierdut activare. ReArm-uri rămase: 1001.
• Pachete Appx scoase ca să treacă sysprep: Microsoft.Winget.Source, Microsoft.Edge.GameAssist, Microsoft.WidgetsPlatformRuntime, Microsoft.StartExperiencesApp, NotepadPlusPlus (versiunea Store; cea desktop a rămas), plus un pachet cu nume GUID.
• Rămășiță inofensivă: folderul C:\Users\defaultuser0 (contul e șters, folderul era blocat de un proces) — dispare la o repornire.

Snapshot de siguranță: pre-sysprep (2026-08-10 23:31, făcut cu VM-ul oprit curat). De șters după ce totul e confirmat:

ssh root@10.0.20.201 "qm delsnapshot 303 pre-sysprep"

Alternativă, dacă SMB tot nu e dorit: VM 201 are OpenSSH pe portul 22 (verificat) — scp fisier.txt romfast@10.0.20.122:/C:/temp/, fără NTLM.

✅ 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