vagrant box add fails when ~/.vagrant.d/boxes is a symlink to an NTFS file system

[PeterJCLaw]

Vagrant version

$ vagrant -v
Vagrant 2.2.3

Vagrantfile

Not sure it's going to be entirely relevant here; I was using a modified version of
https://github.com/PeterJCLaw/sr-server-puppet/blob/8e4a6639facd3f8b3143480a94c850d8582fa682/Vagrantfile which pointed at the fedora/29-cloud-base box rather than the fedora/28-cloud-base image.

Host operating system

Ubuntu 16.04 LTS

Expected behavior

Adding the box should succeed even though the utime of the newly added box was unable to be set.

Actual behavior

Vagrant tried to set the utime of the newly added box, which errored, causing Vagrant to get into an inconsistent state regarding the box.

Command outputs: https://gist.github.com/PeterJCLaw/9d89dd9de99c92f7c0c7d15b98590a6e

Note that vagrant box list shows the downloaded box as present even though it appears to be unusable by vagrant up.

Steps to reproduce

1. be on linux
2. change ~/.vagrant.d/boxes to be a symlink to a folder on a local NTFS partition
3. vagrant box add fedora/29-cloud-base (I strongly suspect the actual box is immaterial)

I realise this is a rather odd thing to do, though it seems unfortunate that vagrant is able to put itself into an inconsistent state over the lack of setting some metadata on the downloaded box.
It's worth noting that as part of getting into this state I moved a number of existing boxes from my ~/.vagrant.d/boxes/ directory to the now-symlinked directory on the NTFS drive and vagrant had seemed completely happy with that for other operations (listing boxes, creating VMs from boxes).

[briancain]

Hey there @PeterJCLaw - Can you confirm that the user used to run Vagrant has the proper permissions to copy something onto that file system? The error seems to be saying that it lacks permissions to move a file into the destination folder, which would be your NTFS file system.

[PeterJCLaw]

Yup, my user account has full access to the target NTFS partition, including write. (I'm assuming vagrant doesn't launch itself as another user or anything).

I'm not surprised that the metadata write failed -- I often get warnings about that from other programs. The files' data usually seems just fine though.

[briancain]

@PeterJCLaw - Does it work or behave differently if you change VAGRANT_HOME to your NTFS partition instead of making a symlink? https://www.vagrantup.com/docs/other/environmental-variables.html#vagrant_home

[PeterJCLaw]

Apologies for the delay, I'd hoped to get to this this evening, but haven't. I'll try to test that tomorrow evening.

For clarity though -- my current setup is that the boxes directory within .vagrant.d/ is the symlink, rather than the whole of .vagrant.d/ being the other side of a symlink. In case it's useful I'll test both making the whole thing a symlink and also setting VAGRANT_HOME (which I'd not realised existed, so thanks for highlighting that!)

[PeterJCLaw]

Ok, so there are four scenarios:

• environment variable, clean directory
• environment variable, pre-populated directory
• symlink, clean directory
• symlink, pre-populated directory

These all fail to chomd the insecure_private_key, with a stack trace along the lines of:

$ VAGRANT_HOME=/media/ntfs-partition/vagrant-home-environment vagrant box add infernix/tinycore
/opt/vagrant/embedded/gems/2.2.5/gems/vagrant-2.2.5/lib/vagrant/environment.rb:1059:in `chmod': Operation not permitted @ chmod_internal - /media/ntfs-partition/vagrant-home-environment/insecure_private_key (Errno::EPERM)
	from /opt/vagrant/embedded/gems/2.2.5/gems/vagrant-2.2.5/lib/vagrant/environment.rb:1059:in `chmod'
	from /opt/vagrant/embedded/gems/2.2.5/gems/vagrant-2.2.5/lib/vagrant/environment.rb:1059:in `copy_insecure_private_key'
	from /opt/vagrant/embedded/gems/2.2.5/gems/vagrant-2.2.5/lib/vagrant/environment.rb:166:in `initialize'
	from /opt/vagrant/embedded/gems/2.2.5/gems/vagrant-2.2.5/bin/vagrant:145:in `new'
	from /opt/vagrant/embedded/gems/2.2.5/gems/vagrant-2.2.5/bin/vagrant:145:in `<main>'

The last (symlink to a copy of an existing .vagrant.d) case works.

(I've used a different box for testing as infernix/tinycore is 15MB versus fedora/29-cloud-base being ~300MB; just for speed of doing the tests)

[PeterJCLaw]

Nope, turns out I messed up the testing of the symlink case. All four cases fail with the same error.

[chrisroberts]

Hi. Attempting to use an NTFS mount from a linux host is not supported and is the root cause of the error you have encountered. This is because NTFS does not provide a POSIX complaint file system implementation.

I am leaving this issue open as the error message generated in not useful or helpful for a user so we will fix that to properly rescue out and provide a better error message.

Cheers!