Vagrant: undefined method `gsub!' for nil:NilClass (NoMethodError)

[narration-sd]

Please note that the Vagrant issue tracker is reserved for bug reports and
enhancements. For general usage questions, please use the Vagrant mailing list:
https://groups.google.com/forum/#!forum/vagrant-up. Thank you!

Vagrant version

Fresh install Vagrant 2.0.0

Host operating system

Windows 10 64 latest

Guest operating system

Ubuntu 16.04 pretty sure

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

require 'json'
require 'yaml'

VAGRANTFILE_API_VERSION ||= "2"
confDir = $confDir ||= File.expand_path("vendor/laravel/homestead", File.dirname(__FILE__))

homesteadYamlPath = "Homestead.yaml"
homesteadJsonPath = "Homestead.json"
afterScriptPath = "after.sh"
aliasesPath = "aliases"

require File.expand_path(confDir + '/scripts/homestead.rb')

Vagrant.require_version '>= 1.9.0'

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    if File.exist? aliasesPath then
        config.vm.provision "file", source: aliasesPath, destination: "/tmp/bash_aliases"
        config.vm.provision "shell" do |s|
            s.inline = "awk '{ sub(\"\r$\", \"\"); print }' /tmp/bash_aliases > /home/vagrant/.bash_aliases"
        end
    end

    if File.exist? homesteadYamlPath then
        settings = YAML::load(File.read(homesteadYamlPath))
    elsif File.exist? homesteadJsonPath then
        settings = JSON.parse(File.read(homesteadJsonPath))
    else
        abort "Homestead settings file not found in #{confDir}"
    end

    Homestead.configure(config, settings)

    if File.exist? afterScriptPath then
        config.vm.provision "shell", path: afterScriptPath, privileged: false
    end

    if defined? VagrantPlugins::HostsUpdater
        config.hostsupdater.aliases = settings['sites'].map { |site| site['map'] }
    end
end

Please note, if you are using Homestead or a different Vagrantfile format, we
may be unable to assist with your issue. Try to reproduce the issue using a
vanilla Vagrantfile first.

Debug output

https://gist.github.com/narration-sd/cd8a7c2a2f7c11d8de404f055c622641

Expected behavior

Vagrant should bring up my site

Actual behavior

Stack trace

Steps to reproduce

1. install 2.0.0 over 1.9.6
2. vagrant up
   3.

References

Are there any other GitHub issues (open or closed) that should be linked here?
For example:

[narration-sd]

In heavy use, multiple vms, so very glad this uninstalled, and 1.9.6 went back in cleanly, functions as before.

[briancain]

Hello @narration-sd - how are you invoking vagrant on windows? Are you using cygwin, or a different terminal? Thanks!

[narration-sd]

Hi @briancain -- last night, I first raised Vagrant via Win10 Vagrant Manager; that's where the stack trace comes from. Later I tried another vm from latest PhpStorm console terminal, another way I usually use.

Are you suggesting this is some kind of PATH order problem?

Cygwin, or at least a Babun version of it is present; also parts of Msys

Up did entirely work reliably for years before....

[narration-sd]

From PhpStorm console; never mind successive Microsoft installers making a usual mess:

\vagrant\gnu\dpprime_html>echo %PATH%
C:\Program Files (x86)Common Files\Intel\Shared Libraries\redist\intel64compiler;C:\Program Files (x86)Common Files\Intel\Shared Libraries\redist\ia32compiler;C:\W
INDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Bitvise SSH Client;C:\Program FilesMicrosoft SQ
L ServerClient SDK\ODBC\110\Tools\Binn\;C:\Program Files\Docker Toolbox;C:MinGW\msys\1.0\bin;C:\php;C:\Program FilesMicrosoft SQL ServerClient SDK\ODBC\130\Tools\B
inn\;C:\Program Files (x86)Microsoft SQL Server\130\Tools\Binn\;C:\Program FilesMicrosoft SQL Server\130\Tools\Binn\;C:\Program FilesMicrosoft SQL Server\130\DTS\Bi
nn\;C:\Program Files (x86)Microsoft SQL ServerClient SDK\ODBC\130\Tools\Binn\;C:\Program Files (x86)Microsoft SQL Server\130\DTS\Binn\;C:\Program Files (x86)Micros
oft SQL Server\130\Tools\BinnManagementStudio\;C:\Go\bin;C:\Program Files\Rust stable GNU 1.12\bin;C:\Program Files (x86)\Skype\Phone\;C:\Program Files\nodejs\;C:\Pro
gram Files (x86)\Yarn\bin;C:\Program Files\TortoiseGit\bin;C:\Program FilesCalibre2\;C:\HashiCorp\Vagrant\bin;C:\Ruby22-x64\bin;C:Users\narra\AppData\Local\atom\bin;
C:\Program Files (x86)\Scapple;C:\Program Files\Docker Toolbox;C:Users\narra\AppData\LocalComposerSetup\bin;C:Users\narra\AppData\LocalMicrosoft\WindowsApps;C:Use
rs\narra.babun;C:Users\narra\AppData\Local\Pandoc\;C:Users\narra\AppData\RoamingComposer\vendor\bin;C:Users\narra\AppData\Roaming\npm;C:Users\narra\AppData\Local
\Yarn\bin;C:Users\narra\AppData\Local\Programs\Git\cmd

C:\vagrant\gnu\dpprime_html>

[narration-sd]

Also, I am using the newer one-vm-per-site arrangement, built from Composer. Also very reliable, better than the old combined way

[briancain]

@narration-sd - the codepath you're hitting with the stacktrace suggests that vagrant thinks you're in cygwin, but the tool cygpath is not present or could not be found (something used to translate windows paths to cygwin paths internally in vagrant which should be installed with cygwin or msys2) which is why I asked how you were running vagrant. I'm not too familiar with how vagrantmanager works, but it looks like vagrant can't seem to find where cygpath is located, and when it tries to escape slashes on nil you get your error.

Long story short, definitely a bug. The behavior in 1.9.6 does not invoke the Which class and just attempts to call cygpath directly, so I think if we put in some guards ensuring cygpath isn't nil prior to escaping slashes, we should be ok.

[narration-sd]

Sounds good, @briancain - thanks. I'll look forward to that fix.

Yes, I try to stay away from cygwin and friends, except where I need it to do docker and ansible builds -- until Winbash gets its act fully together for this; nearly, in the last rev, but not yet. Symlinks the real problem to manage as Composer is also involved.

[narration-sd]

@briancain I had a little more of a think about what you said, and looked around.

cygpath only exists on the machine when I am actually in Babun, a fork of cygwin, or in Git Bash, where a version out of its own C:\Programs... \mingw64 installation is found.

This isn't in the path I provided, and indeed the PhpStorm console, which appears to be just Windows command shell, doesn't find it.

what I am saying is that there is no cygpath accessible to any way I do vagrant up.

I didn't think any part of Cygwin was needed for Vagrant, unless it's one you provide.

So I think a fix has to work as before, without any cygpath calls, no?

Hoping this helps target....

[briancain]

@narration-sd - Ah ok, I think I see what's going on here. I think what happens is vagrant calls out to that cygwin path function to convert windows paths prior to rsync, and the command cygpath isn't present (Because it's vagrant manager), and then raises an exception and uses bash to convert the path instead. Either way I think the solution to this bug is the same, but thanks for the additional info! :)

[narration-sd]

@briancain -- just another data point, since you mention rsync....

I use it intensely, as in note on apparent problems there for another thread: https://github.com/hashicorp/vagrant/issues/8954#issuecomment-329287345

n.b. ...hoping to help you guys get these things all at once...

[solimike]

Since I just blundered straight into this bug trying out Vagrant for the first time with vanilla vagrantfile for centos/7 box on a Win10 host, I thought I'd leave a pointer for the simple workaround: observe the warning in v1708.01 release note that in the absence of rsync you'll need to disable sync folders with:

config.vm.synced_folder ".", "/vagrant", disabled: true

Presumably that stops vagrant trying to invoke rsync at all and thereby avoids the bugged invocation of cygpath.

Hope that workaround saves someone else a few minutes!

[briancain]

@solimike - can you give me more details as to how you ran into this bug? Were you also using vagrantmanager? Or are you invoking vagrant a different way (i.e. cygwin, msys2, powershell....)?

[narration-sd]

@solimike just would remind this bug is primarily about _use_ of rsync, as is very useful to get usefully rapid performance on Windows hosts (along with instant sftp from development IDE).

I think @briancain has this very well in mind, though, appreciated.

[rwowens]

I am getting the same error on my Windows 8.1 system when my guest base is set to centos/7 but when I change the base to hashicorp/precise64, it works fine. This is a fresh install of Vagrant 2.0.0

==> default: Checking for guest additions in VM...
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...
H:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/util/platform.rb:115:in `cygwin_path': undefined method `gsub!' for nil:NilClass (NoMethodError)
        from H:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/plugins/synced_folders/rsync/helper.rb:54:in `rsync_single'

[cranphin]

Ran into this too, clean install, coreos/7, I do have git for Windows installed on my (Windows 7) machine.
Oh, and vagrant up is called from cmd.exe, not bash.

[chrisroberts]

Can you try setting the environment variable: VAGRANT_DETECTED_OS=windows and see if that resolves the issue?

As for why this is only seen with certain boxes is due to the lack of guest additions on the box which causes vagrant to use rsync instead of the native shared folders for the provider.

[solimike]

@narration-sd in response to your question:

can you give me more details as to how you ran into this bug?

I was trying out vagrant for the first time and did a clean install of 2.0.0 on Win10 PC which also has other tools like Cygwin and Git installed. Decided to use CentOS/7 box to give it a spin. Invoked vagrant from Cmd shell, not using vagrantmanager. I was rather alarmed by the stack-trace on first use ;-) but perfectly clear why once I stopped to read the release notes for the box.

I understand the advantages of rsync and why the absence of guest additions matters.

Since a search on the stack trace takes you straight to this ticket, my comment was really intended to stop equally naive vagrant newbies a bit of time. You and @briancain seem to have the bug itself well cornered. :-)

As an aside for @chrisroberts, setting VAGRANT_DETECTED_OS=windows had no effect on my box: I reenabled the synced folder in the vagrantfile to uncover the bug again, then set the environment variable but still hit the stack trace.

[rwowens]

I was discussing this today with a co-worker who is more experienced with Vagrant and he pointed me to the problem. In the centos/7 box, there is a configuration issue. In \.vagrant.d\boxes\centos-VAGRANTSLASH-7\1708.01\virtualbox\Vagrantfile, the following line exists:

config.vm.synced_folder ".", "/vagrant", type: "rsync"

Editing this file to drop the type parameter solved the problem for me. So this seems like a box build problem and not an actual Vagrant problem. Hope that helps someone else.

[cranphin]

@rwowens: Does that actually work? Since the box doesn't have the virtualbox guest additions, all I get when I do that is: "mount: unknown filesystem type 'vboxsf'."

[narration-sd]

@cranphin cc/ @rwowens I think we're well covered on this (for 2.0.1?) due to @briancain 's undertstanding and efforts, but what you say kind of underlines that rsync needs to be able to transparently work as it has in 1.9.x and prior Vagrant, as well as just be 'avoidable' by some who don't feel they want to use it.

[rwowens]

@cranphin All I can say is that it worked for me. I do have the vbguest plugin installed though, so that might be helping me out by automatically updating/installing the guest additions. I agree though that if rsync "just worked," this would all be a non-issue.

[cranphin]

@rwowens: Ahh, vbguest plugin explains it :) For me it's hard to install plugins, since I'm on a nearly offline system.. :)

[cranphin]

My workaround is to add:
config.vm.synced_folder ".", "/vagrant", type: "virtualbox"
To my vagrant file, so that virtualbox folder syncing is used instead of rsync, and then using the "geerlingguy/centos7" box instead, which seems a suitable replacement which has virtualbox guest additions already included.
This lets me develop with Vagrant and CentOS on a offline machine, only needing virtualbox and vagrant installer, and a copy of the specific box.

[eleftrik]

Same problem, none of the above workarounds worked for me.

Windows 7, Vagrant 2.0.0, VirtualBox 5.1.28, Cmder (ConEmu 161206)

With any box, when I try to vagrant ssh-config I got

C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/util/platform.rb:115:in `cygwin_path': undefined method `gsub!' for nil:NilClass (
NoMethodError)                                                                                                                                                
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/util/platform.rb:296:in `format_windows_path'                        
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/plugins/commands/ssh_config/command.rb:16:in `block in convert_win_paths'        
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/plugins/commands/ssh_config/command.rb:16:in `map!'                              
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/plugins/commands/ssh_config/command.rb:16:in `convert_win_paths'                 
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/plugins/commands/ssh_config/command.rb:41:in `block in execute'                  
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/plugin/v2/command.rb:235:in `block in with_target_vms'               
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/plugin/v2/command.rb:229:in `each'                                   
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/plugin/v2/command.rb:229:in `with_target_vms'                        
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/plugins/commands/ssh_config/command.rb:36:in `execute'                           
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/cli.rb:42:in `execute'                                               
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:308:in `cli'                                          
        from C:/Program Files (x86)/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:138:in `<main>'                                                      

If I launch vagrant ssh I got no output.

I am able to SSH into boxes only through Vagrant Manager -> (box name) -> SSH

Thanks

[inequity]

@eleftrik I had the exact same issue as you, but setting VAGRANT_DETECTED_OS=windows fixed it for me.

[eleftrik]

Thank you @inequity, it works!

[cameronkerrnz]

Fairly new Win 10 Enterprise install, with VirtualBox 5.1.30, Vagrant 2.0.0 and no Cygwin; running Vagrant from cmd.exe

VAGRANT_DETECTED_OS=windows set in the environment, but it made no difference.
Disabling rsync shared folders worked though.

I suspect the real issue is that Vagrant (2.0.0) has not decided to use its embedded version of rsync.exe from C:\HashiCorp\Vagrant\embedded\usr\bin\

I was curious as to what it was using for SSH, as the only SSH client I've installed so-far on my fairly virginal system is Putty (I was expecting it to fail). Turns out that it was using ssh.exe from that embedded\usr\bin\ directory, where there is also rsync.exe

This is presumably the embedded\usr\bin\ directory would not be in the PATH, but Vagrant needs to take care to take it into account when looking for rsync, much as it does when looking for ssh.... although trying to read and comprehend Ruby is somewhat beyond me at present.

[hashibot[bot]]

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.