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
  

⚠️ Capcanele sysprep-ului pe o mașină în uz — citește ÎNAINTE de a repeta

Toate au fost întâlnite pe bune și rezolvate. Într-o ordine utilă:

1. <ComputerName> din unattend nu se aplică — mașina a pornit ca WIN-SN6AFCEVSRR. Redenumire ulterioară cu Rename-Computer + repornire.

2. HideLocalAccountScreen NU funcționează pe Windows 11 build 26100. OOBE se oprește oricum la „Who's going to use this device?". Nu există ocolire prin unattend; trebuie completat la consolă.

3. La acel ecran, NU introduce numele unui cont existent. Introducerea lui romfast (cont deja prezent) a agățat OOBE-ul — a urmat oprire forțată și reintrare în OOBE. Introdu un nume nou (ex. setup1), parolă goală ca să sari peste întrebările de securitate, apoi sign out și logare pe contul real.

4. Nu șterge defaultuser0 cât timp OOBE rulează. Sesiunea consolei rulează chiar sub el; ștergerea lui blochează fluxul. Agentul QEMU răspunde ca serviciu indiferent de starea OOBE — deci „agentul răspunde" nu înseamnă că OOBE s-a terminat. Verifică quser: dacă sesiunea activă e defaultuser0, ești încă în OOBE.

5. /generalize șterge HKLM\SYSTEM\MountedDevices → literele de partiție se pierd. Aici au dispărut D: și E: (partițiile 5 și 6 de pe disc 0), iar programele instalate pe D:\roa păreau pierdute. Volumele erau intacte, doar fără literă:

   Set-Partition -DiskNumber 0 -PartitionNumber 5 -NewDriveLetter D
   Set-Partition -DiskNumber 0 -PartitionNumber 6 -NewDriveLetter E
   

   Share-urile (Temp → D:\Temp, D$, E$) au supraviețuit și au redevenit funcționale odată cu literele.

6. Sysprep readuce AutoAdminLogon = 1 — pus înapoi pe 0.

7. RustDesk nu mai accepta parola. /generalize regenerează MachineGuid (acum 386fb2c0-0cf0-443e-9ad4-4bc529db3446), de care sunt legate credențialele stocate. Configurația și serverul (roa.romfast.ro:21116) au rămas; ID nou: 294770995. Parola permanentă se pune din nou:

   & 'C:\Program Files\RustDesk\rustdesk.exe' --password '<parola>'
   Restart-Service RustDesk
   

Stare finală verificată (2026-08-11, ~00:00)

Sesiune activă ca romfast; C: 292 GB, D: 109 GB cu roa/Temp/utils/romfast, E: 97 GB gol — toate Healthy, niciun volum „dirty" după oprirea forțată, zero erori disk/Ntfs/volmgr în System log. Autentificarea NTLM către .122 răspunde sub=0xc000006a (parolă evaluată normal) atât cu prefix ROACENTRAL\ cât și VM-303\.

Închis 2026-08-11: utilizatorul a confirmat că programele merg și că \\ROACENTRAL\temp e accesibil. Contul temporar setup1 și profilul lui au fost șterse, la fel profilul defaultuser0. Pe VM 303 a rămas un singur cont: romfast, cu C:\Users\romfast.

DE FĂCUT (sesiune următoare): decuplarea VM 303 de template-ul defect

VM 303 e încă linked clone din VM 300, deci VM 300 nu poate fi șters:

rpool/data/vm-303-disk-1  origin=rpool/data/base-300-disk-0@__base__   (refer 63.5G)
rpool/data/vm-303-disk-0  origin=rpool/data/base-300-disk-1@__base__   (efidisk)

Transformarea în full clone rupe legătura, iar apoi VM 300 poate fi șters definitiv — scoate din infrastructură imaginea contaminată. Ambele discuri trebuie mutate, nu doar virtio0.

Metoda Proxmox: qm move-disk, cu --delete 1 ca să șteargă volumul sursă:

ssh root@10.0.20.201 "qm shutdown 303"      # oprire curata
ssh root@10.0.20.201 "qm move-disk 303 virtio0 local-zfs --delete 1"
ssh root@10.0.20.201 "qm move-disk 303 efidisk0 local-zfs --delete 1"
ssh root@10.0.20.201 "zfs list -o name,used,refer,origin | grep vm-303"   # origin trebuie sa fie gol
ssh root@10.0.20.201 "qm start 303"

De verificat înainte: unele versiuni PVE refuză mutarea pe aceeași storage. Dacă local-zfs -> local-zfs e refuzat, ruta e prin storage-ul local (dir) și înapoi, sau zfs promote la nivel de storage — de evaluat atunci, nu orbește.

Cerințe: ~64 GB liberi pe local-zfs (la 2026-08-11 erau 242 GB) și oprirea VM 303 pe durata copierii. Snapshot-ul pre-sysprep trebuie șters înainte — un volum ZFS cu snapshot-uri nu poate fi mutat:

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

Acces la \\ROACENTRAL\temp fără cont de administrator

Everyone pe share nu înseamnă acces anonim. Windows 11 blochează implicit logon-ul de tip guest/anonim (EnableInsecureGuestLogons=False, Guest dezactivat și prezent în SeDenyNetworkLogonRight), iar LimitBlankPasswordUse=1 interzice conturile fără parolă la logon prin rețea. Deci e nevoie întotdeauna de un cont real cu parolă — dar nu trebuie să fie administrator.

Permisiunile existente pe .122 (verificate) fac treaba fără nicio modificare de ACL:

Nivel	Permisiune
Share temp	Everyone: Full
NTFS C:\temp	Authenticated Users: Modify, Users: ReadAndExecute

Un cont simplu din grupul Users primește deci Modify (citire + scriere) pe C:\temp, fără drepturi pe restul mașinii. SeNetworkLogonRight include deja S-1-5-32-545 (Users), deci logon-ul prin rețea e permis.

Pe ROACENTRAL (10.0.20.122), ca administrator:

$pw = Read-Host -AsSecureString "Parola pentru contul de share"
New-LocalUser -Name fisiere -Password $pw -PasswordNeverExpires -AccountNeverExpires `
  -Description "Acces \\ROACENTRAL\temp, fara drepturi de admin"
Add-LocalGroupMember -Group Users -Member fisiere

De pe VM 303 (sau orice altă mașină):

net use \\10.0.20.122\temp /user:ROACENTRAL\fisiere *

Contul fisiere nu trebuie adăugat în Administrators. Dacă vrei acces doar de citire, scoate Authenticated Users: Modify de pe C:\temp și lasă doar Users: ReadAndExecute.

• 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