[Bug] Windows: Access denied on llama-server.exe when Studio is run without admin after elevated install

[ZeroGold]

Title: [Bug] Windows: Access denied on llama-server.exe when Studio is run without admin after elevated install

---

Did you update?
pip install --upgrade unsloth unsloth_zoo — yes, running latest.

Colab or Kaggle or local / cloud
Local — Windows 11, NVIDIA RTX GPU

Which Unsloth version, TRL version, transformers version, PyTorch version?
Unsloth Studio v0.1.2-beta, Python 3.13

---

Bug

When unsloth studio setup is run from an elevated (Administrator) terminal, the built llama-server.exe inherits restrictive ACLs. If the user then launches Unsloth Studio without admin privileges (which is the normal case), model validation fails with [WinError 5] Access is denied.

Models load fine in LM Studio using the same GGUF files, confirming the models themselves are valid.

Reproduction

1. Open PowerShell as Administrator
2. Run unsloth studio setup (installs and builds llama-server.exe under ~/.unsloth/llama.cpp/)
3. Close the admin terminal
4. Open a normal (non-elevated) terminal
5. Run unsloth studio
6. Try to load any GGUF model (e.g. unsloth/Qwen3.5-4B-GGUF)
7. Model validation fails with Access is denied

Logs

{"timestamp": "2026-04-04T07:37:52.818254Z", "level": "error", "event": "Error validating model identifier 'unsloth/Qwen3.5-4B-GGUF': [WinError 5] Access is denied: 'C:\\\\Users\\\\[REDACTED]\\\\.unsloth\\\\llama.cpp\\\\build\\\\bin\\\\Release\\\\llama-server.exe'", "exc_info": true}
{"timestamp": "2026-04-04T07:37:52.818697Z", "level": "info", "event": "request_completed", "method": "POST", "path": "/api/inference/validate", "status_code": 400, "process_time_ms": 69.05}

Temporary workaround

Run Unsloth Studio as Administrator (right-click → Run as administrator). This works but shouldn't be required for normal use.

Suggested fix

The setup script should ensure llama-server.exe (and other built binaries) are accessible to the installing user's normal (non-elevated) account. Potential approaches:

1. Post-build permission fix: After building llama-server.exe, run icacls to grant BUILTIN\Users read+execute access, so it works regardless of elevation context
2. Detect elevated install: Warn the user during setup that installing as admin may cause permission issues, and offer to fix ACLs automatically
3. Startup detection: If Studio detects [WinError 5] at runtime, check whether admin privilege mismatch is the cause and surface an actionable error message instead of a generic "Invalid model" 400
4. Elevate on startup (not recommended): As a last resort, Studio could request admin privileges on launch via UAC. This would work but adds unnecessary friction and violates least-privilege principles — the real fix should ensure the binary is accessible without elevation.

I've already prototyped option 3 (runtime detection with ctypes.windll.shell32.IsUserAnAdmin() + retry-with-backoff for transient file locks). If this isn't addressed in a couple weeks, I'm happy to put together a PR covering both the install-time fix and the runtime fallback.

Related issues

• Fix orphan server cleanup killing user's own llama-server #4622 — Fix orphan server cleanup killing user's own llama-server
• [Bug] Windows 11 Installation Issues. #4487 — Windows 11 Installation Issues (Access is denied)
• [Bug] Unsloth Studio installation fails on Windows 11 with scoop #4701 — Installation fails on Windows 11 with scoop (Access is denied)
• First experience of using Unsloth Studio - Feedback #4668 — First experience feedback (truncated error messages)

[rolandtannous]

@ZeroGold why are you installing with elevated permissions if you don't mind me asking?

[ZeroGold]

@rolandtannous I couldn't tell you, I installed it without thinking.

I was on the website, then ran the install command to get things started.

Command:
irm https://unsloth.ai/install.ps1 | iex

• After doing the onboarding there were some loading issues with training screen and the chat screen.
• I closed the app because of loading issues with training screen and chat screen, then re-opened to reassess.
• This is what happened afterward, my models wouldn't load at all including the ones I install from Unsloth.

My thought is that setup should probably handle the admin portion more gracefully.

[ZeroGold]

Update: The issue also blocks unsloth studio setup from running again. Even re-running setup to fix things fails because Test-Path can't access the binary:

Test-Path : Access is denied
At C:\Users[REDACTED].unsloth\studio\unsloth_studio\Lib\site-packages\studio\setup.ps1:1875

• if (Test-Path $LlamaServerBin) {

• ~~~~~~~~~~~~~~~~~~~~~~~~~
  

[ERROR] unsloth studio setup failed (exit code 1)

So the user can't run Studio or fix the install without manually taking ownership of the directory or running as admin again.

[rolandtannous]

I don't have access to a windows machine, but i'd imagine that admin doesn't by default install for all users on windows?
It should work though if you install without elevated permissions as that is the intended behavior. Would be great if you can confirm.

[ZeroGold]

I will take a look today and will report back my findings.

[ZeroGold]

@rolandtannous
Did testing yesterday with default permissions

After digging into the full installer log, this is actually two related problems:

1. SYSTEM profile path resolution in subprocess
   The prebuilt llama.cpp install fails because the subprocess resolves to the SYSTEM account's profile rather than the current user's:
   Access is denied: 'C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps'
   This should be C:\Users<user>\AppData\Local.... This was from a non-elevated PowerShell session, so the likely cause is Python being installed system-wide (via winget/MSI), which causes the spawned subprocess to inherit a SYSTEM-context path. The relevant call is at setup.ps1:1768.
2. Test-Path fails with UnauthorizedAccessException
   After the prebuilt path fails and it falls back to source build, Test-Path $LlamaServerBin itself throws UnauthorizedAccessException at setup.ps1:1875 — the script can't even check whether the binary exists.

Full logs

Installing prebuilt llama.cpp bundle (preferred path)...

Existing llama.cpp install detected -- validating staged prebuilt update before replacement

llama.cpp prebuilt install failed (continuing)

| python.exe : [llama-prebuilt] existing llama.cpp install detected at 
| C:\Users\<user>\.unsloth\llama.cpp; validating staged prebuilt update before replacement
|
| At C:\Users\<user>\.unsloth\studio\unsloth_studio\Lib\site-packages\studio\setup.ps1:1768 char:35
| + $prebuiltOutput = & python @prebuiltArgs 2>&1 | Out-S ...
| + ~~~~~~~~~~~~~~~~~~~~~~~~~~~
|     + CategoryInfo          : NotSpecified: ([llama-prebuilt...ore replacement:String) [], RemoteException
|     + FullyQualifiedErrorId : NativeCommandError
|
| [llama-prebuilt] prebuilt install path failed; falling back to source build
| [llama-prebuilt] prebuilt fallback reason: failed to inspect published releases in ggml-org/llama.cpp:
| [WinError 5] Access is denied:
| 'C:\\Windows\\system32\\config\\systemprofile\\AppData\\Local\\Microsoft\\WindowsApps'
|
| [llama-prebuilt] fatal helper error:
| [WinError 5] Access is denied:
| 'C:\\Windows\\system32\\config\\systemprofile\\AppData\\Local\\Microsoft\\WindowsApps'

Prebuilt update failed; existing install was restored or cleaned before source build fallback

Prebuilt llama.cpp path unavailable or failed validation -- falling back to source build

OpenSSL dev found at:
C:\Program Files\OpenSSL-Win64

Test-Path : Access is denied

At C:\Users\<user>\.unsloth\studio\unsloth_studio\Lib\site-packages\studio\setup.ps1:1875 char:5
+ if (Test-Path $LlamaServerBin) {
+     ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied:
      (C:\Users\<user>\..lama-server.exe:String) [Test-Path], UnauthorizedAccessException
    + FullyQualifiedErrorId :
      ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.TestPathCommand

[ERROR] unsloth studio setup failed (exit code 1)

[rolandtannous]

llama.cpp was a different issue. we changed the way the system works.
can you reinstall from a clean sheet and try without elevated permissions if you don't mind. thanks

[aiSynergy37]

Opened PR #4881 with a fix for this:

• catches UnauthorizedAccessException during llama-server.exe path checks in studio/setup.ps1
• normalizes ACLs on ~/.unsloth/llama.cpp via icacls so non-elevated sessions can execute binaries after elevated setup
• adds regression tests for the new guards

Validation run: pytest tests/studio/install/test_pr4562_bugfixes.py -k setup_ps1 -v

[rolandtannous]

still waiting for response on can you reinstall from a clean sheet and try without elevated permissions if you don't mind. thanks

[aiSynergy37]

Thanks for the nudge - agreed that clean-sheet reinstall without elevation should be the primary path.

For context, PR #4881 is scoped as a hardening/recovery fix for the access-denied state (especially when existing llama.cpp binaries/directories inherit restrictive ACLs):

• avoids setup abort on UnauthorizedAccessException from Test-Path
• attempts ACL normalization so users can recover without manual ownership steps

So even if clean non-elevated reinstall now works, this patch is intended to make setup resilient when users end up in the restricted-permissions state.

If you prefer, I can retitle/split this to explicitly track recovery hardening separately from clean-install behavior verification.

[rolandtannous]

I'll get back to you on this one

[ZeroGold]

Just started a clean sheet install so you can have something to reference. Give me some time to get back with the results.