dynamic host volumes: fix Windows compatibility

[olljanat]

Description

Revisit logic added by #25533 and make sure that it does not break Windows compatibility.

Without this volume creation targeting to Windows node failed to error:

Error creating volume: Unexpected response code:
 500 (rpc error: rpc error: HostVolume.Create error:
 error changing owner/group:
 chown c:\opt\nomad\data\host_volumes\688372d2-c709-de26-5718-effd054bb95a: not supported by windows)

Testing & Reproduction steps

name = "example"
node_id  = "<node id>"
type = "host"
plugin_id = "mkdir"
capability {
  access_mode  = "single-node-single-writer"
  attachment_mode = "file-system"
}

nomad volume create volume.hcl

Links

Contributor Checklist

• Changelog Entry If this PR changes user-facing behavior, please generate and add a
  changelog entry using the make cl command.
• Testing Please add tests to cover any new functionality or to demonstrate bug fixes and
  ensure regressions will be caught.
• Documentation If the change impacts user-facing functionality such as the CLI, API, UI,
  and job configuration, please update the Nomad product documentation, which is stored in the
  web-unified-docs repo. Refer to the web-unified-docs contributor guide for docs guidelines.
  Please also consider whether the change requires notes within the upgrade
  guide. If you would like help with the docs, tag the nomad-docs team in this PR.

Reviewer Checklist

• Backport Labels Please add the correct backport labels as described by the internal
  backporting document.
• Commit Type Ensure the correct merge method is selected which should be "squash and merge"
  in the majority of situations. The main exceptions are long-lived feature branches or merges where
  history should be preserved.
• Enterprise PRs If this is an enterprise only PR, please add any required changelog entry
  within the public repository.

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

[olljanat]

Rebased just in case.

@tgross PTAL

[mismithhisler]

If os.Chown always returns an error on windows, should we just wrap the chown in a if runtime.GOOS != "windows"?

[olljanat]

That would works too but isn't that bad that user might expect to set permissions which is not actually done?

Based on code -1 means change nothing so current logic would works exactly same way in both Linux and Windows as long user do not configure permissions but any other value would still give error not supported by windows

[mismithhisler]

Good point! Also, I apologize for belaboring this, but I was curious how this was handled elsewhere in the codebase (it's not the only place we use os.Chown(). It looks we only chown when the euid from syscall.Geteuid() is 0. I wonder if, for consistency sake, we should do something similar here? This syscall returns -1 on Windows. See here for reference.

Either way, I think it's probably useful for someone on the Nomad team (I can do this) to update the mkdir plugin docs to let Windows users know that ownership changing is not available on Windows.

[tgross]

I wonder if, for consistency sake, we should do something similar here?

I'd like to get away from doing that where we can, in hopes of being able to support rootless Nomad at some point. And for this PR I think it makes sense to just fix the Windows issue directly and not introduce a new constraint.

[olljanat]

Updated, "test-windows" failure looks like build server issue for me:

2025-12-04T07:32:16.694Z [INFO]  docker/driver.go:406: docker: created container: container_id=b9a531e20c2f720a11f573b6c44f827666ad3869ac3ff80948cb38e351092009
2025-12-04T07:32:16.702Z [DEBUG] docker/driver.go:598: docker: failed to start container: container_id=b9a531e20c2f720a11f573b6c44f827666ad3869ac3ff80948cb38e351092009 attempt=1 error="Error response from daemon: failed to create endpoint redis-demo-882e0f50-50be-e48d-3019-d4eb0dc09069 on network nat: failed during hnsCallRawResponse: hnsCall failed in Win32: The process cannot access the file because it is being used by another process. (0x20)"

Not sure if that happens often in here but if it does, my recommendation would be switch to Windows Server 2025 based build servers.

There is no official release notes about this but based on my stress testing it seems that Microsoft has improved HNS stability in Win 2025.

[tgross]

Not sure if that happens often in here but if it does, my recommendation would be switch to Windows Server 2025 based build servers.

Yes, it's super flaky! Thanks for the recommendation!

[tgross]

LGTM!

@mismithhisler is going to follow-up with docs updates.