Go 1.25 + Windows Nano Server

[tianon]

TLDR: Go 1.25 exposes a bug in the Windows Nano Server images (specifically in the value they use for TMP) -- we need to investigate and decide how to best fix, work around, or drop.

---

Chasing the rabbit hole of the error:

testing golang:1.25rc1-nanoserver-ltsc2022
	'override-cmd' [1/2]...passed
go: open C:\Windows\TEMP: Access is denied.
	'golang-hello-world' [2/2]...failed

It seems that the new version of go tries to access the $TMP directory, which should be readable and writable by the running user.

nanoserver images have these values in their environment variables

TEMP=C:\Windows\TEMP
TMP=C:\Windows\TEMP
USERNAME=ContainerUser

😭 Every mcr.microsoft.com/windows/nanoserver image, from the first 1809 (aka ltsc2019) through ltsc2025 has TMP and TEMP set to the system temporary directory, but the default user (ContainerUser) doesn't have permission read its contents (or write to it).

Earlier nanoserver images (like 1803) have the correct setting based on the user (e.g C:\Users\ContainerUser\AppData\Local\Temp for the default user) and it auto adjusts if you run as ContainerAdministrator which is how the windows/servercore images work.

Adding -e TMP=C:\Users\ContainerUser\AppData\Local\Temp -w C:\Users\ContainerUser\AppData\Local\Temp is enough to get go working again (i.e., set the temp env var and make sure the directory exists).

So, we have a few options that I see:

• disable the nanoserver builds on 1.25-rc
• set TMP and TEMP via ENV in the Dockerfile (or maybe setx like PATH?)
  • what value works for any user?
• set USER ContainerAdministrator
  • 👎less secure
• give ContainerUser read/write permissions to C:\Windows\temp
  • this also seems less secure
• convince windows to fix the nanoserver images to auto set TMP and TEMP like they did in 1803

---

related:

• preview-nanoserver-1809 temp folder does not have list permissions PowerShell/PowerShell-Docker#188
• Docker sample does not work on Windows microsoft/artifacts-credprovider#448

Originally posted by @yosifkit in #562 (comment)

[tianon]

I think the most correct fix would come from Microsoft, but I know better than to hold my breath for that. 😭

Do we know why it's broken now and works fine on 1.24? What's changed in 1.25 that causes the failure? 🤔

(Maybe we should also revisit Windows-based tip images so we can catch things like this sooner 😅 🙈 😭)

(moving from #562 (comment))

[tianon]

Something really screwy is happening here -- I can create files and directories in C:\Windows\TEMP, but I cannot list that directory (and if I write files directly in there, I cannot read them, they're write-only). If I create a directory and remember where it is and just use it, it works fine. If I do go run it works fine and uses C:\Windows\TEMP just fine (but with extra errors the first time, then if I run it again ... it swaps to C:\Users\ContainerUser\AppData\Local\go-build\xxx and then no longer errors).

C:\go>echo foo > C:\Windows\TEMP\foo.txt

C:\go>type C:\Windows\TEMP\foo.txt
Access is denied.

C:\go>mkdir C:\Windows\TEMP\foobar

C:\go>cd C:\Windows\TEMP\foobar

C:\Windows\Temp\foobar>dir
 Volume in drive C has no label.
 Volume Serial Number is 0A2F-9FED

 Directory of C:\Windows\Temp\foobar

06/12/2025  12:04 PM    <DIR>          .
06/12/2025  12:04 PM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  21,298,311,168 bytes free

C:\Windows\Temp\foobar>echo hi > file.txt

C:\Windows\Temp\foobar>type file.txt
hi

C:\Windows\Temp\foobar>dir
 Volume in drive C has no label.
 Volume Serial Number is 0A2F-9FED

 Directory of C:\Windows\Temp\foobar

06/12/2025  12:06 PM    <DIR>          .
06/12/2025  12:04 PM    <DIR>          ..
06/12/2025  12:06 PM                 5 file.txt
               1 File(s)              5 bytes
               2 Dir(s)  21,298,069,504 bytes free

[tianon]

The more I dig/test, the more convinced I am that C:\Windows\Temp is fine, actually, and that this is a bug in Go 1.25 that we ought to bisect. 😞

[tianon]

After a very long bisect session (thanks mostly to compile times), it's golang/go@6d41809:

6d418096b2dfe2a2e47b7aa83b46748fb301e6cb is the first bad commit
commit 6d418096b2dfe2a2e47b7aa83b46748fb301e6cb
Author: Damien Neil <dneil@google.com>
Date:   Fri Mar 28 16:14:43 2025 -0700

    os: avoid symlink races in RemoveAll on Windows

    Make the openat-using version of RemoveAll use the appropriate
    Windows equivalent, via new portable (but internal) functions
    added for os.Root.

    We could reimplement everything in terms of os.Root,
    but this is a bit simpler and keeps the existing code structure.

    Fixes #52745

    Change-Id: I0eba0286398b351f2ee9abaa60e1675173988787
    Reviewed-on: https://go-review.googlesource.com/c/go/+/661575
    Reviewed-by: Alan Donovan <adonovan@google.com>
    Auto-Submit: Damien Neil <dneil@google.com>
    LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

 src/internal/syscall/unix/constants.go      |  2 +-
 src/internal/syscall/unix/nofollow_posix.go |  2 +-
 src/internal/syscall/windows/at_windows.go  |  4 ++--
 src/os/path_windows.go                      | 10 +++++++++
 src/os/removeall_at.go                      | 32 +++++++++--------------------
 src/os/removeall_noat.go                    |  2 +-
 src/os/removeall_unix.go                    | 20 ++++++++++++++++++
 src/os/removeall_windows.go                 | 17 +++++++++++++++
 src/os/root_unix.go                         | 12 +++++++++++
 src/os/root_windows.go                      | 10 ++++++++-
 10 files changed, 83 insertions(+), 28 deletions(-)
 create mode 100644 src/os/removeall_unix.go
 create mode 100644 src/os/removeall_windows.go

[tianon]

I've filed golang/go#74134 to get some upstream attention (now that I've bisected it).