search

hashicorp / vagrant

Vagrant is a tool for building and distributing development environments.
https://www.vagrantup.com
Other
26.15k stars 4.42k forks source link

VMware issues with VAGRANT_HOME on external drive #9292

Closed Kier closed 6 years ago

Kier commented 6 years ago

I'm running out of space on my SSD, so I want to move all my base boxes etc. to another drive. I've tried all manner of reinstallations and reconfigurations but the end result is always the same - the VMware plugin seems to be very much against VAGRANT_HOME being on a different drive.

I've defined VAGRANT_HOME to point to the new location and verified that it's exported properly, then fully reinstalled vagrant with a clean config after errors resulted, reinstalled and re-licenced the VMware plug in, but still I get the same message with various vagrant commands - 'Vagrant has detected that the VMware plugin is not properly setup'.

More details and debug output below.

Vagrant version

Host operating system

MacOS High Sierra

Guest operating system

(any)

Vagrantfile

(doesn't get that far...)

Debug output

https://gist.github.com/Kier/6e7e28f3d70c072cb2e6b28a72b757f0

Expected behavior

Specified base box is added

Actual behavior

"Vagrant failed to initialize at a very early stage:

Vagrant has detected that the VMware plugin is not properly setup. Please reinstall the VMware plugin and run this command again. If this error persists please contact support."

Steps to reproduce

  1. Define a new VAGRANT_HOME in .bash_profile and ensure the variable is exported properly
  2. Do a clean install of vagrant
  3. Try to 'box add' a pre-built VMware-based box
CmptrExpr commented 6 years ago

I've permanently added the environment variable in Windows and this works:

VAGRANT_HOME=E:\VM.vagrant.d

However, before you use it, move your ~/.vagrant.d to the new path, then start a new shell/prompt to pick up the environment change.

I've also modified the default location of VirtualBox to allocate VM's in the E:\VM path directory.

Kier commented 6 years ago

I should have mentioned - I have a similar setup on my laptop, where I've set VAGRANT_HOME=/Users/kier/VMs/Vagrant and that works fine - it's just on my desktop that I can't escape the error no matter what I do. I was hoping that someone would see something in the debug gist that might offer a solution.

briancain commented 6 years ago

@Kier could you provide us with the output of mount on your system? Thanks!

Kier commented 6 years ago

@briancain I'm not sure if mount or diskutil will give you a better insight, so here is the output from both.

A little extra info - the system is a late 2014 iMac 5K running High Sierra with a 256GB internal SSD, and the external disk is a LaCie 6Big running over Thunderbolt, configured with RAID 5 via LaCie RAID Manager, which I assume means that it's running with hardware RAID rather than a software-based system. Both are formatted with APFS.

$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            218.7 GB   disk1s1
   2:                APFS Volume Preboot                 24.3 MB    disk1s2
   3:                APFS Volume Recovery                506.6 MB   disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *40.0 TB    disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         40.0 TB    disk2s2

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +40.0 TB    disk3
                                 Physical Store disk2s2
   1:                APFS Volume LaCie                   7.4 TB     disk3s1
   2:                APFS Volume Preboot                 20.5 KB    disk3s2
   3:                APFS Volume Recovery                20.5 KB    disk3s3
   4:                APFS Volume VM                      20.5 KB    disk3s4

# before time machine runs
 $ mount
/dev/disk1s1 on / (apfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s4 on /private/var/vm (apfs, local, noexec, journaled, noatime, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk3s1 on /Volumes/LaCie (apfs, local, nodev, nosuid, journaled, noowners)
//;AUTH=No%20User%20Authent@MyCloud._afpovertcp._tcp.local/Plex on /Volumes/Plex (afpfs, nodev, nosuid, mounted by kier)

# after time machine runs
$ mount
/dev/disk1s1 on / (apfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s4 on /private/var/vm (apfs, local, noexec, journaled, noatime, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk3s1 on /Volumes/LaCie (apfs, local, nodev, nosuid, journaled, noowners)
//;AUTH=No%20User%20Authent@MyCloud._afpovertcp._tcp.local/Plex on /Volumes/Plex (afpfs, nodev, nosuid, mounted by kier)
com.apple.TimeMachine.2018-01-03-122741@/dev/disk1s1 on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Big Tasty/2018-01-03-122741/Macintosh HD (apfs, local, read-only, journaled, nobrowse)
com.apple.TimeMachine.2018-01-03-132459@/dev/disk1s1 on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Big Tasty/2018-01-03-132459/Macintosh HD (apfs, local, read-only, journaled, nobrowse)
com.apple.TimeMachine.2018-01-03-142235@/dev/disk1s1 on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Big Tasty/2018-01-03-142235/Macintosh HD (apfs, local, read-only, journaled, nobrowse)
com.apple.TimeMachine.2018-01-03-152313@/dev/disk1s1 on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Big Tasty/2018-01-03-152313/Macintosh HD (apfs, local, read-only, journaled, nobrowse)
com.apple.TimeMachine.2018-01-03-172335@/dev/disk1s1 on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Big Tasty/2018-01-03-172335/Macintosh HD (apfs, local, read-only, journaled, nobrowse)
com.apple.TimeMachine.2018-01-03-162320@/dev/disk1s1 on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Big Tasty/2018-01-03-162320/Macintosh HD (apfs, local, read-only, journaled, nobrowse)
com.apple.TimeMachine.2018-01-03-192702@/dev/disk1s1 on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Big Tasty/2018-01-03-192702/Macintosh HD (apfs, local, read-only, journaled, nobrowse)
com.apple.TimeMachine.2018-01-03-182241@/dev/disk1s1 on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Big Tasty/2018-01-03-182241/Macintosh HD (apfs, local, read-only, journaled, nobrowse)
briancain commented 6 years ago

@Kier - So the problem with your external drive is that it has the nosuid option enabled.

/dev/disk3s1 on /Volumes/LaCie (apfs, local, nodev, nosuid, journaled, noowners)

The vmware vagrant plugin uses a Golang binary wrapper that requires using setuid, and that mount setting on your drive disables that from happening. If you remove that setting, the vmware plugin should be able to work on that drive. Thanks!

Kier commented 6 years ago

Thanks, @briancain

Kier commented 6 years ago

I may be missing something obvious here, but can anyone suggest a way to get that drive to mount without nosuid?

On 4 Jan 2018, at 18:23, Brian Cain notifications@github.com wrote:

Closed #9292 https://github.com/hashicorp/vagrant/issues/9292.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hashicorp/vagrant/issues/9292#event-1410048734, or mute the thread https://github.com/notifications/unsubscribe-auth/AASsQl5_vFrlH_KTBKHiTzWWE-aG5hmtks5tHRc1gaJpZM4RJ6nO.

stephenreay commented 6 years ago

I seem to be facing this issue too. I've literally just purchased the plugin, but there is no documentation from Hashicorp about this not being a supported use-case for the plugin.

Saying what needs to be done, without any reference as to how it can be done isn't an acceptable response when we've paid money for something that is literally unusable in its current state.

stephenreay commented 6 years ago

If anyone else comes across this, a temporary solution (i.e. one that needs to be re-run every time the external volume is re-mounted) is to run the following:

sudo mount -u -o suid,nodev /Volumes/your-volume-name

This will change the mount options of the volume to enable suid, but keep the existing nodev option it likely has.

I've thus-far been unable to find an option that will cause autofs on macOS to correctly mount a given volume without nosuid set

stephenreay commented 6 years ago

If you want to make it detect the volume path automatically, the following should work (e.g. I put it in a shell function in my .bash_profile:

sudo mount -u -o suid,nodev "${VAGRANT_HOME%/${VAGRANT_HOME#/Volumes/*/}}"

ghost commented 4 years ago

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.