-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to create temporary directory when running win_template module against Windows Server 2019 #608
Comments
The problem here doesn't look like anything to do with
Something is breaking internally in the ssh daemon that is causing an access denied failure. Unfortunately for an error such as this it's going to be something environment specific as it's a fundamental issue with trying to start powershell.exe to run our code. |
I thought that initially as well, however, in the It's a separate issue, but when researching that error message I found multiple threads reporting that that access denied error occurs when running powershell commands from a non-interactive ssh session. This thread explains that it's an issue with specific versions of OpenSSH, where powershell doesn't handle data sent to stdout in a non-interactive ssh session. And when decoding the encoded powershell command, there is a |
Ah I see, the temp directory is created and outputted as expected but as the return value of the process to create the temporary directory is not 0 the connection plugin sees the command as a failure. Unfortunately at the point in time the rc is being checked is not something this collection can control, it's part of shared code inside Ansible which validates whether the return code was 0 or not. This would need to fixed on the transport layer to ensure that a non-zero rc is not returned for scenarios like this unfortunately. |
From what I can tell the error is being caused by attempting to create a temp directory that already exists. Decoding the temp directory path, it seems that a timestamp is included in the temp directory name, most likely to avoid the issue of creating duplicate directory names. However, because the same directory gets created twice, it seems that it's not generating a new directory name for the |
That can't happen as the temporary directory has enough randomness in it to avoid conflicts. The shell plugin uses _generate_temp_dir_name to create the directory name which uses both time, the pid, and a random integer between 0 and 2^48. The temporary directory is also scoped to each task so doing subsequent Set-StrictMode -Version Latest
$tmp_path = [System.Environment]::ExpandEnvironmentVariables('%TEMP%')
$tmp = New-Item -Type Directory -Path $tmp_path -Name 'ansible-tmp-1714509461.069503-301-253568139436398'
Write-Output -InputObject $tmp.FullName
If (-not $?) { If (Get-Variable LASTEXITCODE -ErrorAction SilentlyContinue) { exit $LASTEXITCODE } Else { exit 1 } } One of the last step is to output the temporary directory which if we look at the stdout we can see that is the case:
If it was an issue where the same directory is created twice stderr would contain the error
There's nothing about the output that would indicate it's being created twice, it seems like it's being created but because of the internal error in PowerShell about the output stream it is exiting with 1 causing the subsequent failures. You need to solve the problem with ssh here to ensure it doesn't return the rc of 1. |
The reason I say that the same temp directory is getting created twice is because if I decode the command for the
Which is the exact same command down to the temp path that gets sent during the |
I think your output might be mixed and the messages you see is actually for the template task and not the |
Ahh, that makes a lot of sense. The log output format is a bit weird, and that definetly explains why it looks like it's creating the same folder twice. Thanks for all your help. |
For anyone else that runs into this issue, I solved it. It's specifically caused by PowerShell transcription getting turned on (HKLM:\SoftwarePolicies\Microsoft\Windows\PowerShell\Transcription EnableTranscripting). This setting seems to interact weirdly with the version of OpenSSH 7.7p1, which was causing the |
Awesome glad you figured what the underlying cause was. A pity the OpenSSH server is causing issue with it though. |
It's unfortunate that this issue was closed, I am running into it again on Server 2022 Datacenter Version 10.0.20348.2762 "Core" (No Desktop Experience). In my case, a bunch of tasks run correctly including many Then a simple # For docs on how this works on windows, see ':help $VIM' and ':help version'
- name: Set up global vimrc
ansible.windows.win_copy:
src: files/vimrc
dest: '{{ _neovim_exe.result.ParentDirectory }}\share\nvim\sysinit.vim'
when: _neovim_exe.result | length # Skip when _neovim_exe was not found This is the Playbook `-vvv` output
@jborean93 As you can see we connect as the local "Administrator" via SSH. Just like in @dwierima-aspentech case, the temp directory is being created correctly (it's empty):
Also maybe worth noting, we are NOT running the built-in Feature-on-Demand version of OpenSSH, we install the newer versions from GitHub. This VM was running Why does this snippet: Set-StrictMode -Version Latest
$tmp_path = [System.Environment]::ExpandEnvironmentVariables('%TEMP%')
$tmp = New-Item -Type Directory -Path $tmp_path -Name 'ansible-tmp-1730972635.5356016-6559-80339554844547'
Write-Output -InputObject $tmp.FullName
If (-not $?) { If (Get-Variable LASTEXITCODE -ErrorAction SilentlyContinue) { exit $LASTEXITCODE } Else { exit 1 } } even exit with |
AHA! The same task succeeds unchanged when running against the same exact VM, just uninstalled OpenSSH v9.8.1.0p1-Preview and replaced it with the older OpenSSH v9.5.0.0p1-Beta: Same task completing successfully now
EDIT: v9.8.0.0p1-Preview exhibits the same problem so it was a regression from 9.5 to 9.8 by Microsoft... EDIT2: I have opened and issue in the Win32-OpenSSH repository: PowerShell/Win32-OpenSSH#2296 Let's see if Microsoft cares, last few times I had SSH issues they were brushed off as wontfix and dontcare despite them simultaneously pushing SSH as the new defacto remoting standard....... sigh |
@jantari thanks for tracking it down and for opening the issue, let's hope they are able to fix the problem. Just as an FYI with the official support of SSH done in 2.18 https://docs.ansible.com/ansible/devel/os_guide/windows_ssh.html we only officially support and test the FoD version shipped with Windows and starting with Server 2022. That's not to say 2019 and 2016 won't work we don't officially support it. |
SUMMARY
Running win_template module against a Windows 2019 Server results in a 'Failed to create temporary directory' error. This same behavior is not exhibited by Windows Server 2022, Windows desktop 10 or 11, when running the exact same play. I believe this is due to win_template attempting to create a temporary directory that was already created in a previous play.
For instance in my most recent testing I see the following path in stdout of the win_template play, and the previous win_path play: "C:\Users\username\AppData\Local\Temp\ansible-tmp-1714509461.069503-301-253568139436398"
However, when I decode the same play when run against Windows server 2022, ansible doesn't even appear to be creating a temporary directory.
I have a lot of plays in this playbook, and I have attempted shuffling around the order that the plays in the playbook get called, and adding a 5 second pause prior to running the win_template play, however the win_template play always throws the error. Which is why I believe that this error is caused by win_template.
ISSUE TYPE
COMPONENT NAME
win_template
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
STEPS TO REPRODUCE
EXPECTED RESULTS
Running the above play produces the following output on Windows Server 2022, where the file is templeted out correctly.
ACTUAL RESULTS
Running the same play as above produces the following output on Windows Server 2019, where an unreachable error occurs.
I included both the play which produces an error and the previous play to show that they both create the same temp directory.
The text was updated successfully, but these errors were encountered: