MSI update always fails with Error 1310 (System error 1307 ERROR_INVALID_OWNER) writing .rbf temp file in install dir; REINSTALLMODE=omus workaround works #53

Summary

The AltServer MSI auto-updater graphically fails with Error 1310 "Error writing to file: D:\AltServer<random>.rbf — System error 1307 (ERROR_INVALID_OWNER)" on every update attempt. As far as I can tell the cause is that, when overwriting an existing file, the MSI re-applies the security descriptor of the previous file, and the previous file's owner SID is the interactive user — so when msiexec (running as SYSTEM) tries to set the new file's owner it fails with 1307. This reproducible loop persists even after manually fixing the ownership of the target directory.

Environment

• Windows 11 Pro (26200.9445), single-user NTFS system, AltServer installed to D:\AltServer (custom non-default directory)
• AltServer 1.7.4 → attempting update to 1.7.5 (both via in-app auto-update and by manually running the downloaded 1_7_5.msi / AltInstaller.msi from E:)

Repro

1. AltServer (1.7.4) installed previously under D:\AltServer
2. Trigger update (auto-update picked up 1.7.5 from %TEMP%\Update-<guid>\1_7_5.msi, or double-click the MSI directly)
3. Halfway through, the installer pops:

Error writing to file: D:\AltServer\5452d1e.rbf. Verify that you have access to that directory.

4. Every "Try Again" fails with the same 1307 error. Retrying whole installs always produces a new .rbf file name (e.g. 5452d21.rbf) and the same failure.

Things I verified before filing (so this isn't a config problem on my end)

• I can write to D:\AltServer and to the failing .rbf path directly as the user / even while msiexec is running:
  • [IO.File]::Open(...,'Open','ReadWrite','None') → OK
  • [IO.File]::WriteAllBytes(...) → OK
• ACLs on D:\ and D:\AltServer are the Windows defaults; tried normalizing owner to SYSTEM, applying icacls /reset /t, granting SYSTEM/Administrators full control — none of it changed anything. The installer still fails with 1307 on the .rbf temp file it creates in that directory.

Workaround that actually works

Running the MSI non-interactively from an elevated command prompt with a reinstall mode that forces overwrite of the old file's security info:

msiexec /i path\to\AltInstaller.msi REINSTALLMODE=omus

With that flag the same MSI installs cleanly (verified successfully going 1.7.4 → 1.7.5 this way — verbose log ends with "Installation completed successfully", status 0). Running the identical MSI without the flag fails graphically every time.

This strongly suggests the failing step is the "apply security descriptors from the previous file" pass (based on my handle-level tests above, the user process can write fine, and the only oddity in my setup is that files in D:\AltServer were originally created with my user account as owner).

Notes

• Haven't found any other issue on GitHub mentioning this; first time it happened I checked existing issues before filing.
• Being on the D:\ drive instead of the default C:\ install path might be relevant, but the same behavior is likely for anyone who's previously run AltServer under a non-SYSTEM owner and just updates in place.