File provisioner on macOS Mojave 10.14.3 fails to properly copy folders #10662
Comments
|
Hello @angoras - I don't think that issue is related. It's taking already existing variables and just printing information. What does your folder |
|
Oh, okay. I just noticed you are using a file provisioner. I have to ask, is |
|
@briancain Yes, it's a folder with some text files and a subfolder with additional text files. |
|
@angoras - if you want to sync a folder, you need to use the config.vm.synced_folder "conf/vagrant", "home/vagrant"The file provisioner is only for files, not folders. That would explain the odd behavior. Thanks! |
|
@briancain But this is not a synced folder, it's just copied during the provision. Like the last example here: |
|
@angoras - you can use rsync for that if you just one a one time copy to the guest:
https://www.vagrantup.com/docs/synced-folders/rsync.html config.vm.synced_folder "conf/vagrant", "home/vagrant, type: "rsync" |
|
@briancain The "file" provisioner is used to copy folders into the VM, and it works with my configuration, but not with my coworkers, who gets the same error messages as @angoras. Also the documentation clearly says this
You can see that for yourself here: https://www.vagrantup.com/docs/provisioning/file.html So, you saying to use the I will try and get the debug output and version numbers for ruby, gem, vagrant etc. once my coworker gets to the office. EDIT: sorry for the harsh tone. But this is really something driving me up the wall very easily, completely ignoring the original issue and instead just offering a replacement, when clearly the original approach is a regression that used to be working before. |
|
@dgollub - Okay, it does look like the file provisioner for whatever reason does support folders. @angoras - I've also tried to reproduce the error, and it doesn't happen with the latest version: config.vm.define "bork" do |b|
b.vm.box = "bento/ubuntu-18.04"
b.vm.provision "Sandbox", type: "file",
source: "linux-sandbox/Vagrantfile",
destination: "/home/vagrant/test/Vagrantfile"
b.vm.provision "file",
source: "conf/vagrant",
destination: "/home/vagrant"
b.vm.provider :virtualbox
endI've used the same path names as the original issue, and Vagrant is able to copy everything just fine as expected. It would be helpful to know what is exactly in your folder that you are expecting to copy over to the guest. My guess is maybe there's an issue with the name of a file you have in that folder. Still, I will still stand by my original suggestion and say that the synced_folder option (with rsync if you must only sync once) is still a much more sane option for something like this. The file provisioner uses |
|
@briancain Thanks for your reply. I have gathered additional information, and this all - to me at least - points to a combination of the Vagrant source itself in tandem with the new macOS 10.14.x as source for the issue. Unfortunately I do not have a Linux nor a Windows host machine to verify whether or not this is purely a Vagrant issue or purely a macOS 10.14.x issue. Anyway, here is more information, and I did this all on my MacBook Pro with macOS 10.14.2 (18C54). Vagrantfile part
Starting point is Vagrant version 2.2.0, installed when I was still on macOS 10.13.x, and back then using the However my coworker got a new MacBook Pro with macOS: 10.14.3 (18D109) and installed Vagrant 2.2.3, and the provisioning using the Debug output says basically the same the one @angoras posted. I then went ahead and upgrade my Vagrant to 2.2.3 as well, and tried So I tried downgrading to the following versions:
Also, the 2.1.5 log had this extra debug output, that the 2.2.0 and 2.2.3 one did not have (I am referring to the This line here looks suspicious More details. My environment is as follows Coworker: For now we decided to list all files separately in the Vagrantfile instead of using the folder directly with the Also, since this is a real regression, this issue should be re-opened in my opinion (or create a new one with a better title maybe). |
Thanks for investigating. I really don't think the filenames has got anything to do with it. They have been the same for almost a year, and worked across many versions of both vagrant and MacOS. I'm sorry to say that I upgraded both vagrant from 2.2.2 to 2.2.3 and MacOS from 10.14.2 to 10.14.3 at the same time, so I don't know where the problem originated.
Thanks, I will try that instead. Maybe this should be mentioned in the documentation then? :-) |
briancain
changed the title
|
The problem is with a recent OpenSSH patch. See my analysis here: lavabit/robox#40. |
|
Hey all. I'm going to go ahead and close this one in favor of #10675 as it seems to have more information as to the actual bug here with net-scp. Thanks! |
|
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. |
ghost
locked and limited conversation to collaborators
Vagrant version
2.2.3
vagrant-hostsupdater (1.1.1.160, global)
vagrant-share (1.1.9, global)
vagrant-vbguest (0.17.2, global)
Host operating system
MacOS 10.14.3
Guest operating system
ubuntu/xenial64 (virtualbox, 20190208.0.0)
Vagrantfile
Debug output
https://gist.github.com/angoras/e1138fc79b1b56da892298ff1ca39274
Expected behavior
The directory (including some files) should be copied into the guest, as described here:
https://www.vagrantup.com/docs/provisioning/file.html
Actual behavior
The script terminates with the above error.
The problem is this line:
config.vm.provision "file", source: "conf/vagrant", destination: "/home/vagrant"
It used to work, but with the latest update, 2.2.3, it stopped working. If every file is copied separately it still works, but not when defined on the directory level. Maybe it has got something to do with [GH-10570]?
Steps to reproduce
The text was updated successfully, but these errors were encountered: