Are symlinks supported?

[ztsmith]

I read through this issue on Bitbucket: https://bitbucket.org/jankowfsky/winnfsd/issues/4/symlinks
It was closed which I took it to mean symlinks are now supported in winnfsd.
However when I try to create a symlink I get an error

$ ln -s ~/dir1 dir2
ln: failed to create symbolic link ‘dir2’: Input/output error

This is on an Ubuntu 14.04 VM that is loaded via Vagrant/VirtualBox.
I've seen a lot of blog posts about enabling symlinks in VirtualBox, but all seem to be specific to Vbox shared folders.

Is someone able to clarify the current status on Symlinks?

[yannschepens]

Hi, symlink only work with Windows pro. Be sûre you use it.

Currently, i have no other returns about problems relative to symlink.

Which release of plugin do you use ?

Le mar. 11 août 2015 18:40, ztsmith notifications@github.com a écrit :

I read through this issue on Bitbucket:
https://bitbucket.org/jankowfsky/winnfsd/issues/4/symlinks
It was closed which I took it to mean symlinks are now supported in
winnfsd.
However when I try to create a symlink I get an error

$ ln -s ~/dir1 dir2
ln: failed to create symbolic link ‘dir2’: Input/output error

This is on an Ubuntu 14.04 VM that is loaded via Vagrant/VirtualBox.
I've seen a lot of blog posts about enabling symlinks in VirtualBox, but
all seem to be specific to Vbox shared folders.

Is someone able to clarify the current status on Symlinks?

—
Reply to this email directly or view it on GitHub
#66.

[ztsmith]

I'm using:

• win 8.1 pro
• vagrant-winnfsd 1.1.0
• Vagrant 1.7.4

I tried running Vagrant from an admin prompt but it didn't help.

In my example: $ ln -s ~/dir1 dir2
dir1 is the non-NFS (target) location where the actual files will be, dir2 is the NFS mount dir that I want to be a symlink to those files.

Is there anything I need to install or upgrade in Ubuntu? I'm using the "ubuntu/trusty64" box from Atlas without modification.

[ztsmith]

For an easy repo, the following Vagrantfile should help:

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"

  config.vm.network "private_network", type: "dhcp" 
  config.vm.synced_folder ".", "/vagrant", type: "nfs"

  config.vm.provider :virtualbox do |vbox|
    vbox.name = "nfs-test"
    vbox.memory = 2048
  end

end

then ssh into the box and run

/vagrant $ mkdir ~/target
/vagrant $ ln -s ~/target mylink

This should fail with the above error.

[kadet1090]

@ztsmith Are you running winnfsd as admin? Windows is stupid and allows symlink only for admin users (even, if that is changed in windows group policy settings :C). If not, just check "Run as administrator" in winnfsd,exe properties and it should work (At least it was working well for me)

[arathunku]

I've got similar config and the same problem. I've ran console as admin and winnfsd.exe is also checked to be used as administrator. Are there any logs I could get instead of just "Input/output error"?

I'm using Windows 10.

[seemsindie]

Can someone help me with this, i ran console as admin where i ran vagrant up and i can see folder mounted. But when i try to create a ln -s ~/node_modules ./node_modules i get:

ln: failed to create symbolic link ‘node_modules’: Input/output error

And i have this in config:

vb.customize ["setextradata", :id, "VBoxInternal2/SharedFoldersEnableSymlinksCreate/projects", "1"]

Any ideas why it's not working?

[worthwhileindustries]

@seemsindie do you have guest additions installed? Not sure if that's the problem but, worth asking.

[marcharding]

@seemsindie, @ztsmith it seems you want to symlink across mount points? I do not think this will be possible (i doubt that works with any nfs implementation). Or is ~ also a nfs share?

[seemsindie]

@marcharding Well i dont' have the machine up any more, running linux :(
But what i was trying to do is to have my node_modules folder outside of mounted folder, but to have it just as symlink, and the folder to be on the host in home dir.

[marcharding]

@seemsindie okay, that will not work, since that would be a symlink across file system boundaries (home is not a subfolder of your mount, right?).

since the nfs server must resolve the symlink, it would look for the node_modules folder on the host but the folder only exist on the guest home folder (or vice versa). i think that would be the same with every nfs server.

Since you're running linux now, you probably don't care 😄, but it would be possible using bindfs and remounting ~/node_modules into the mounted nfs path.

Something like bindfs --perms=rwxrwxrwx ~/node_modules /vagrant/node_modules on the vagrant guest would probably work.

Normal symlinks inside the mounted folder should work quite well with v1.2.0.

[seemsindie]

@marcharding yes home is not a subfolder of my mount, it's a folder on linux fs. And i wanted to symlink it to my mounted folder :)

[bernhardberger]

symlinks with a Windows host just drive me crazy. No problems at all in Windows 7 with an admin account - in Windows 10 there seems to be no solution whatsoever without running that damn cmd as admin which is just not possible in my case as it depends on the current users' paths and settings..

Any further ideas to work around this? I even switched to this winnfsd plugin in hope that I would get around that..

[marcharding]

If you can't run as in an elevated shell you can try this.

[bernhardberger]

Unfortunately this only works if the user is a non-admin user which kind of feels a little pervert.. if your user has admin rights you're pretty much out of luck..

The problem with this is that I wouldn't actually need symlinks to work or be represented on the windows host as I basically have the whole vagrant layer only to have a working unix system under my docker system as an abstraction..

[bernhardberger]

...the real issue behind this is that it's impossible to run from an elevated shell as it screws up not only the IDE workflow but also messes with any user profiles and mounted network shares/paths that are created using the windows account.

With this symlink issues around it is almost impossible to introduce a dev box into the workflow of even a small team of 5 people..

[marcharding]

I do not really get how an elevated shell messes with user profiles, mounted network shares or an overall workflow. You do not even need to use it after winnfsd.exe is started...

Anyway: If winnfsd.exe is not started with elevated rights,exe (or the workaround above), no symlinks. That is a limitation of windows and there is sadly nothing we can do to fix that.

[bernhardberger]

Because none of those paths etc are available inside the cmd with elevated privileges.

Just running winnfsd as admin was the hope I had when coming here, but sadly this isn't enough..

[marcharding]

Seems to me that the issue is not winnfsd but the overall setup? You also said in windows 7 everything worked but not in windows 10?

[a-r-m-i-n]

Well, in Windows you need to have Administrator privileges, to create symbolic links. Because winnfsd is not asking for admin rights, it is also not allowed to create symlinks.

When you create a symlink in guest, in shared nfs folder, winnfsd must ask for admin rights (on windows host) and then it should be able to create symlinks.

Of course the symlink and the target of the symlink must be both located in nfs share.

Would be a nice feature.

[martixy]

@ArminVieweg Thanks for the reminder. I keep forgetting symlinks in Win require elevated priv. Also that winnfsd is the thing that actually interacts with the OS.
When you elevate winnfsd, it correctly creates symlinks.

I don't see this as an issue with this module actually - it's about the OS's security model.

[a-r-m-i-n]

@martixy How do I elevate winnfsd? Or did I miss it in this thread?

[a-r-m-i-n]

Oh I missed the link. I try this. Thanks!

[martixy]

@ArminVieweg Well, I simply set winnfsd to run as admin. That's the easiest version.

But frankly allowing non-admins to create symlinks(from marcharding's link) is a much better solution than elevating winnfsd.