Occasional "Access is denied." on vagrant provision with

[Spamme1]

Vagrant version

1.9.1

Host operating system

Ubuntu 14.04.5 LTS

Guest operating system

Windows 2012 r2 (devopsgroup-io/windows_server-2012r2-standard-amd64-nocm)

Vagrantfile

 $name=File.basename(Dir.getwd)
  $uid=0
  for i in 0..$name.length-1
    $uid+=$name[i].ord
  end

  $ip="172.16.11.#{$uid%30+20}"
  config.vm.network "public_network", bridge: "em1", ip: $ip, use_dhcp_assigned_default_route: true
  
  # This is a workaround to set the default gateway for the bridge connection because the parameter use_dhcp_assigned_default_route doesn't work
 config.vm.provision "Gateway", type: "shell", run: "always", inline: <<-POWERSHELL
    $ni=Get-NetIPAddress -IPAddress "#{$ip}"
    New-NetRoute -InterfaceIndex $ni.InterfaceIndex -NextHop "172.16.11.1" -DestinationPrefix "0.0.0.0/0"
  POWERSHELL

  config.vm.provision "Update", type: "shell", run: "never", inline: <<-POWERSHELL
    choco upgrade all -y
  POWERSHELL

Debug output

https://gist.github.com/Spamme1/e86dc1d2f90a83c44c89b3e4cfe9a14a

Expected behavior

Vagrant provision is executed successfully

Actual behavior

Occasionally the second provision can't be executed because "access is denied"
There is no other process accessing the virtual machine, and as you can see from the log file the vagrant provision command is executed immediately after the vagrant reload command.
The question is: Could it be that the machine is still locked from the vagrant reload command?
At the moment I will try to add a pause of 10 sec between the two commands and see if the error will disappear.

Steps to reproduce

1. Create a Jenkins' job
2. Add a "execute shell" build step with the following commands:

vagrant reload
vagrant provision --provision-with Update

3. Execute the Jenkins' job, eventually the error will occur

References

#7968

[chrisroberts]

Related: packer-community/winrmcp#8

[Spamme1]

Update: Since a week, since I have added a 10 seconds pause between the "reload" and the "provision" commands in the Jenkins' job, I haven't seen any more errors.

vagrant reload
sleep 10s
vagrant provision --provision-with Update

[Spamme1]

Two weeks without errors, I'm quite sure that the problem is caused by the execution of the second commands immediately after the first one. I can imagine that vagrant spawns new threads, which are still working when vagrant main thread ends, what could cause the "access is denied", if another vagrant command is executed immediately after.

[Spamme1]

Now is over one month since I have added the pause of 10s between the two commands and the error never appeared again.

[chrisroberts]

@Spamme1 Are you still encountering this on recent versions of Vagrant?

[Spamme1]

We are running 1.0.1 version at the moment, I cannot really say if it has been solved or not, effectively adding a pause of 10s between the commands solved a lot of "build failures", nevertheless we have still daily "build failures" from vagrant deployment, and the solution was to repeat the build automatically after a failure up to three times. Normally in three retries one is working correctly.
The most common problem is an error in the WinRM connection

==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: WinRM address: 127.0.0.1:2200
    default: WinRM username: vagrant
    default: WinRM execution_time_limit: PT2H
    default: WinRM transport: negotiate
An error occurred executing a remote WinRM command.

[chrisroberts]

Hi there,

It looks like this has been resolved within a previously shipped version of Vagrant so I am now closing this issue. If the original issue was not fully resolved, please reopen this issue or create a new one.

Cheers!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.