Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arbitrary host reports missing path on vagrant up #59

Closed
cuviper opened this issue Nov 29, 2016 · 7 comments
Closed

Arbitrary host reports missing path on vagrant up #59

cuviper opened this issue Nov 29, 2016 · 7 comments

Comments

@cuviper
Copy link

cuviper commented Nov 29, 2016

I have a config line something like this:

config.vm.synced_folder "/path/on/other/host", "/path/on/guest", type: "sshfs", ssh_host: "other.host"

When I run vagrant up, I get:

There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* The host path of the shared folder is missing: /path/on/other/host

That path doesn't exist on the local host, only on the remote server that I'm trying to link up.

If I edit the config so this mount is disabled, I can start up; then I re-enable it and run vagrant sshfs --mount, and it's fine. So at least I know the specified paths are ok.

Is there a way to get this to play nice automatically on vagrant up?

(Using vagrant 1.8.7 and vagrant-sshfs 1.3.0)

@cuviper
Copy link
Author

cuviper commented Nov 29, 2016

Looks like vagrant 1.9.0 was just released today, but it doesn't change the behavior here.

@dustymabe
Copy link
Owner

dustymabe commented Nov 29, 2016

hmm. so this is actually a check in vagrant that happens before this plugin is engaged. The vagrant code (outside of this plugin) assumes you are mounting a directory from your host machine into the guest as this is how all of the other synced folder plugins work. Under that assumption, this "check" would make sense.

We can try to find the code within vagrant and submit a PR to not do this and/or only do it under certain circumstances, but I'm not sure how receptive they will be :(

@cuviper
Copy link
Author

cuviper commented Nov 29, 2016

I tried making empty paths locally to get past this, but it appears to have canonicalized the path. This is a problem of its own, as my host is Win10 and the alt server is Linux. It turned into C:/path/on/other/host, which of course won't work either.

As a kludge, I'd be ok with requiring separate vagrant up and vagrant sshfs --mount commands. Is there something I could detect to dynamically set that disabled flag depending on the command? i.e. automatically disable it when coming up, then enable for vagrant sshfs only.

@geerlingguy
Copy link

I'm kinda stuck here too—I want to use a reverse mount, but it's seemingly impossible to do that in Windows, because if I set disabled: true in the config, I can't mount it with vagrant sshfs --mount either.

I'm also getting the error:

The capability 'sshfs_reverse_is_folder_mounted' could not be found. This is an internal error
that users should never see. Please report a bug.

(This happens after I vagrant up with disabled: true, then manually change disabled: false and run vagrant sshfs --mount.)

This is on Windows 7, with Vagrant 1.9.2 and VirtualBox 5.1.18.

@cuviper
Copy link
Author

cuviper commented Mar 28, 2017

I'm currently using disabled: !ENV["SSHFS"], which works ok. Start it up, set the environment, then mount.

@geerlingguy
Copy link

@cuviper - Good idea! Unfortunately, I'm still getting that error above... I'm trying to do a reverse mount (from guest to host), and I wonder if that's some unrelated bug.

@dustymabe
Copy link
Owner

hey @geerlingguy - I initially only supported reverse mounting on linux hosts and then someone requested that I add it for mac in #46. I can't remember now if I didn't implement it for windows because I didn't have time or if there was some technical reason. Created a new issue for that here: #74

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants