Mounting problem on Windows 8.1

[billmn]

I'm using Laravel Homestead box ( http://laravel.com/docs/homestead ) and your awesome plugin to allow NFS on WIndows 8.1 Pro but I have some problem on mounting folders.

I've changed this line to force to use NFS on Windows https://github.com/laravel/homestead/blob/master/scripts/homestead.rb#L45

But when I run "vagrant up" I see this:

Thoughts?

[nunocodex]

If anyone have issue with new Windows 10 after some hours i found a simple solution (why i not thinking before...), need only use a Windows 8 compatibity mode on this file: C:\Users{{username}}.vagrant.d\gems\gems\vagrant-winnfsd-1.0.11\bin and set to compatibility windows 8.

Screenshots: Before without any modification:

And now:

Set to windows 8:

[lecajer]

+1 Can't mount share folder with NFS on Windows 8.1 when the folder isn't into the Vqgrqnt project folder. Simple workaround : put all you folder into the Vagrant project folder (where you do vagrant up)

==> myVM: Preparing to edit nfs mounting file.
[NFS] Status: running
==> myVM: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o 'vers=3,udp,nolock' 192.168.33.1:'/D/Path/Path/Project

Stdout from the command:

Stderr from the command:

mount.nfs: access denied by server while mounting 192.168.33.1:/D/Path/Path/Project
`

[nunocodex]

from your comment i don't see the target directory inside the vagrant machine, you missed one param?

[FractalizeR]

I have similiar problem:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o 'noatime' 172.28.128.1:'/D/PHPProjects/fh/auth' /var/www/auth

Stdout from the command:

Stderr from the command:

mount.nfs: mount system call failed

[nunocodex]

@FractalizeR you tried my previous suggestion?

[FractalizeR]

No, I didn't, sorry. I don't want to mix my projects like that for now. I corrected my Vagrant script to fall back to VB's internal sharing mechanism when host OS is Windows until this is fixed.

[bleleve]

Hi there,

I am on Win 8.1 and I was facing the same problem. I set the compatibilty mode to Windows 8 and it works fine for me too !

Cheers namaless ;)

[borisschapira]

I've set the compatibility mode. It seems to work nicely for a "one-project" vagrant but as usual, on a multi-project vagrant (as described in june https://github.com/GM-Alex/vagrant-winnfsd/issues/12#issuecomment-47316869), that does not work :cry:

[pinano]

I am also on Windows 8.1. Even after setting the compatibility mode to Windows 8 I can't get to run more than two machines with an nfs share simultaneously.

If I'm about to start the third machine and I previously kill winnfsd.exe, the folder will mount but, obviously, I will loose the previous two mountpoints of the machines opened previously.

If I then go and vagrant reload the previous two machines, no matter what I do I always end up with a maximum of two nfs working machines. The third one never gets to mount.

Does anybody else have this same issue where they cannot start more than two machines with an nfs share?

[borisschapira]

@pinano As already mentioned, I cannot mount multiple folders, whether they're on the same or different hosts.

[pinano]

@borisschapira the funny thing is that I can mount up to two folders, whether it is on the same project or in two different projects, but I cannot get to mount the third one. It feels as if it was a limitation of winnfsd somehow, although it doesn't make much sense to me...

[borisschapira]

@pinano Hum, you're right, it seems that I have the same issue, with two folders but no more. I was misled by my provisionning configuration, but you're right, I have one provisioning folder and one project folder that mount. It's the second project folder (so, the third folder) that does not work.

What's funny is that when the log is activated with :

if Vagrant.has_plugin?("vagrant-winnfsd")
    config.winnfsd.logging = "on"
end

the third folder appears in the logged NFS requests... same behaviour on your install ?

[nakanaa]

I'm having the same problem when using dduportal/boot2docker. WinNFSd window was printing NOTIMP (not implemented) so I tried debugging it today. The message comes from PortmapProg.cpp where the program is waiting for a packet to ask for port mappings.

I found a RFC about the port mapping which says that the correct procedure is PMAPPROC_GETPORT which WinNFSd is waiting for. If it sees something else it discards it and prints NOTIMP. For some reason WinNFSd is only getting PMAPPROC_DUMP at least with dduportal/boot2docker. I then tried to debug it on a chef/debian-7.6 box and to my suprise it was sending PMAPPROC_GETPORT and everything worked fine!

So at least in my case it's something to do with the box itself. At least SMB shares are working with dduportal/boot2docker so I'll stick with that for now.

[pinano]

@borisschapira What happens in my install, once I have been examining the logs, is that it mounts the first folder, then it mounts the second folder, and when I vagrant up the third machine it tries to mount the second folder again instead of the third one.

I am pasting a piece of the winnfsd log to see if it makes sense to anyone. I have replaced the actual folder names with project1, project2 and project3 for the sake of simplicity and to show the order the machines are booted up.

I have also inserted some comments where something relevant is going on:

=====================================================
WinNFSd v2.0
Network File System server for Windows
Copyright (C) 2005 Ming-Yang Kao
Edited in 2011 by ZeWaren
Edited in 2013 by Alexander Schneider (Jankowfsky AG)
=====================================================
Path #1 is: C:\dev\webroot\project2, path alias is: /C/dev/webroot/project2
Path #2 is: C:\dev\webroot\project3, path alias is: /C/dev/webroot/project3
Path #3 is: C:\dev\webroot\project1, path alias is: /C/dev/webroot/project1
Portmap daemon started
NFS daemon started
Mount daemon started
Local IP = 172.28.128.1
Type 'help' to see help

# Vagrant up project1 machine (IP 192.168.56.101) and it mounts project1 folder
PORTMAP GETPORT 100003 2049
NFS NULL OK
PORTMAP GETPORT 100005 1058
MOUNT NULL
MOUNT NULL
MOUNT Path C:\dev\webroot\project2 with path alias  /C/dev/webroot/project2 already known
Path C:\dev\webroot\project3 with path alias  /C/dev/webroot/project3 already known
Path C:\dev\webroot\project1 with path alias  /C/dev/webroot/project1 already known
MNT from 192.168.56.101
Final local requested path: C:\dev\webroot\project1

# Vagrant up project2 machine (IP 192.168.56.201) and it mounts project2 folder
PORTMAP GETPORT 100003 2049
NFS NULL OK
NFS FSINFO C:\dev\webroot\project1  OK
NFS PATHCONF C:\dev\webroot\project1  OK
NFS FSINFO C:\dev\webroot\project1  OK
PORTMAP GETPORT 100003 2049
NFS NULL OK
PORTMAP GETPORT 100005 1058
MOUNT NULL
MOUNT NULL
MOUNT Path C:\dev\webroot\project3 with path alias  /C/dev/webroot/project3 already known
Path C:\dev\webroot\project1 with path alias  /C/dev/webroot/project1 already known
Path C:\dev\webroot\project2 with path alias  /C/dev/webroot/project2 already known
MNT from 192.168.56.201
Final local requested path: C:\dev\webroot\project2

# Vagrant up project3 machine (IP 192.168.56.202) and it tries to mount project2 folder !!!
PORTMAP GETPORT 100003 2049
NFS NULL OK
NFS FSINFO C:\dev\webroot\project2  OK
NFS PATHCONF C:\dev\webroot\project2  OK
NFS FSINFO C:\dev\webroot\project2  OK
PORTMAP GETPORT 100003 2049
NFS NULL OK
PORTMAP GETPORT 100005 1058
MOUNT NULL
MOUNT NULL
MOUNT Path C:\dev\webroot\project1 with path alias  /C/dev/webroot/project1 already known
Path C:\dev\webroot\project2 with path alias  /C/dev/webroot/project2 already known
Path C:\dev\webroot\project3 with path alias  /C/dev/webroot/project3 already known
MNT from 192.168.56.202
Final local requested path: C:\dev\webroot\project2

...

# It tries to mount project2 folder 8 times like shown above and then it fails with a
# mount.nfs: acces denied by server while mounting 192.168.51.1:/C/dev/webroot/project3

@nakanaa The boxes I'm using are all Ubuntu 14.04. Do you suggest switching to Debian to see if the behaviour is any different?

[dave-newson]

After some extensive testing, I believe this is a fault with the winnfsd service. vagrant-winnfsd itself isn't to blame, but could be modified to help avoid this problem.

When requesting a mount, winnfsd appears to be comparing the length of the alias, and then comparing the content. If an alias of greater length comes first, it is incorrectly matched as the "final local requested path".

For instance, this works just fine (some stuff omitted):

config.vm.synced_folder "./www", "/data/www"
config.vm.synced_folder "./etc/test", "/data/test"
config.vm.synced_folder "./etc/nginx", "/data/nginx"
config.vm.synced_folder "./etc/t33st", "/data/t33st"

But in the following, a request for /www will result in a match to to /t33st, because it is of greater length and comes first.

config.vm.synced_folder "./etc/t33st", "/data/t33st"
config.vm.synced_folder "./www", "/data/www"
config.vm.synced_folder "./etc/test", "/data/test"
config.vm.synced_folder "./etc/nginx", "/data/nginx"

Additionally, vagrant-winnfsd leaves the winnfsd service running when the vagrant instance is halted. If you then modify the nfspaths file used by winnfsd, either manually or by changing your Vagrantfile and starting your vagrant instance once more, the previous aliases will remain in memory of winnfsd, but it will still try to pattern match using the content from the nfspaths file.

The end result is a mis-matching alias map, causing all sorts of weird issues that make absolutely no sense. To fix this, simply kill the winnfsd instance if you make any modifications to your shares.

In short, the workarounds are:

• Ensure your shares are listed in length-ascending order
• Ensure you kill winnfsd if you modify your shares list

Because of this, it would be an enhancement if:

• vagrant-winnfsd could write (its own?) nfspaths file, which the paths in length-ascending order.
• vagrant-winnfsd enforced the restarting of the winnfsd service on vagrant star.

Failing that, someone should go fix winnfsd.

I debugged this in Windows 8.1, turning on logging manually in nfsservice.bat.

[borisschapira]

@dave-newson thanks for this deep debugging, I will try that ASAP !

[borisschapira]

@dave-newson I confirm everything you said, now it works.

I've find another temporary solution : declare all my sync folders in an array and reorder the array in length-ascending order before declaring them to vagrant for synchronization : https://github.com/borisschapira/vagrant-template/blob/master/Vagrantfile#L62

Thanks a lot, again.

[FractalizeR]

Will this be included into the core? :)

[AssemAfify]

@dave-newson thanks a lot it works, i just rearranged my shared folder in my homestead.yaml in ascending order according to length and everything work fine

Thanks a lot for all who contributed in this post, specially @borisschapira and plugin author ofcourse

[IbnSaeed]

@borisschapira Thanks for the fix. Your fix works with my setup for multiple folder sharing in windows 8.1

[bbodenmiller]

Thanks @dave-newson. Hopefully this gets fixed so I don't have to sort my sync folders list.

[majidaldo]

running with win8 compatibility worked for me. weird.

[prograhammer]

For anyone having problems with Laravel Homestead and a Windows host, I've made this Gist here: https://gist.github.com/prograhammer/9493ee04f30dd74e121b This should help in overcoming all the issues in the whole process (including the winnfsd fixes mentioned here). With this Gist I successfully have Homestead running, being able to use symlinks (ie. for npm install) and overcoming the Windows long file-path character length restriction, and other problems.

[vaske]

I still have this issue on win 8.1 is there any generic solution so far?

[borisschapira]

@vaske see my comment on 12 Mar : https://github.com/winnfsd/vagrant-winnfsd/issues/12#issuecomment-78489636

You must put your sync folders in alpha/length order. I propose a way to do it in https://github.com/borisschapira/vagrant-template/blob/master/Vagrantfile, L15 to L62.

[mthompson182]

The quick fix for me that works fine 1) vagrant halt (does not stop the winnfsd.exe) 2) Go to Task Manager and end the process winnfsd.exe 3) vagrant up

It works fine after doing this, like dave-newson said, it does not stop the winnfsd.exe when you do a vagrant halt, so I just stop it manually. I never had to do anything with sync folders.

[bdw429s]

@borisschapira Must the shares be ordered by the host path or the guest path? Also, if using relative paths, must the expanded path be sorted, or just the relative portion?

If this is a bug in the plugin, is there a dedicated ticket for it somewhere. There are handful of issues related to shared not working but they all have a very large amount of similar comments with no apparent resolution so it's hard to even tell which issues are really for what in this repo.

[borisschapira]

@bdw429s Host path ("from" : https://github.com/borisschapira/vagrant-template/blob/master/Vagrantfile#L62). I don't understand you relative vs. expanded path question. If the relative path are sorted, the expanded are too because they share the same root...

[zek]

I've just changed actimeo=1 to nolock,vers=3,udp and set compatibility to w8.

It works like a charm! I'm using Windows 10 64 bit.

[yannschepens]

Cool. Really cool

Le sam. 26 sept. 2015 16:28, Talha Zekeriya Durmuş notifications@github.com a écrit :

I've just changed actimeo=1 to nolock,vers=3,udp and set compatibility to w8.

It works like a charm! I'm using Windows 10 64 bit.

— Reply to this email directly or view it on GitHub https://github.com/winnfsd/vagrant-winnfsd/issues/12#issuecomment-143454663 .

[amirbilu]

I have struggled for few hours with vagrant freezes on "default: Mounting NFS shared folders". I found out Winnfsd is using port 1058 which was taken by some other process on my machine.

Hope this will save some time for others.

[altmind]

@amirbilu hit the same problem. tcp port 1058 is taken by windows "Policy Agent" service. This service is related to IPSec. net stop PolicyAgent helps

[patricknelson]

Dear googler's: For anyone having issues with vagrant freezing on the Mounting NFS shared folders be sure to start vagrant with the --debug flag so you can see exactly why to help debugging.

@dave-newson's fix above works for me (https://github.com/winnfsd/vagrant-winnfsd/issues/12#issuecomment-78195957) in at least allowing me to mount one of my shares as NFS. The remaining shares cannot be mounted. In my case:

config.vm.synced_folder "../websites", "/websites", type: 'nfs' # Shorter alias (second param)
config.vm.synced_folder ".", "/etc/puppet", id: "vagrant-root" # Will not mount as 'nfs'.

Where /etc/puppet uses the default share (in my case vboxsf). Currently I'm unsure if this is because it's declared second (and thus only one can mount) or if it's something else. At this point I've given up :joy:

[raupie]

I had issues with the winnfsd process not ending on vagrant-destroy and trying to launch another machine. I found this work around to be very helpful, it implements vagrant triggers.

In vagrantfile...

config.trigger.after :destroy do info "Destroy winnfsd process" run "Taskkill /IM winnfsd.exe /F" end

[hcanning]

Disable your firewall and check if the winnfsd process is running.

I needed to allow winnfsd.exe in my Vipre firewall at C:\users\myuser\.vagrant.d\gems\2.6.6\gems\vagrant-winnfsd-1.4.0\bin\winnfsd.exe May help someone.