npm errno -5 with NFS

[jamesmacwhite]

I'm getting various errors from npm during a standard npm -i relating to rename and rmdir syscalls.

My setup is a Windows 10 host running a Ubuntu Linux Vagrant VM with vagrant-winnfsd plugin 1.2.0 installed. vagrant up is run as administrator so npm doesn't explode when installing packages that use symlinks (--no-bin-links is evil). This resolved the issue when running the standard vboxsf setup.

Since switching to NFS with this plugin I was having problems with various npm related commands, so I decided to remove node_modules directory and rebuild. Extract process goes OK, so data within node_modules is being read and written OK but once npm gets to the install stage, I then get failures like this:

npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "i"
npm ERR! node v5.10.1
npm ERR! npm  v3.8.3
npm ERR! path /home/vagrant/code/node_modules/.staging/arraybuffer.slice-0e4436bf
npm ERR! code EIO
npm ERR! errno -5
npm ERR! syscall rename

npm ERR! EIO: i/o error, rename '/home/vagrant/code/node_modules/.staging/arraybuffer.slice-0e4436bf' -> '/home/vagrant/code/node_modules/arraybuffer.slice'

In addition lots of warnings like the examples below:

npm WARN install:acorn@2.7.0 EIO: i/o error, rename '/home/vagrant/code/node_mod                                   ules/.staging/acorn-24e2beb6' -> '/home/vagrant/code/node_modules/acorn'
npm WARN finalize Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modules/                                   .babel-runtime.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize  { [Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modu                                   les/.babel-runtime.DELETE']
npm WARN finalize   errno: -5,
npm WARN finalize   code: 'EIO',
npm WARN finalize   syscall: 'rmdir',
npm WARN finalize   path: '/home/vagrant/code/node_modules/.babel-runtime.DELETE                                   ' }
npm WARN finalize Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modules/                                   .bufferutil.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize  { [Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modu                                   les/.bufferutil.DELETE']
npm WARN finalize   errno: -5,
npm WARN finalize   code: 'EIO',
npm WARN finalize   syscall: 'rmdir',
npm WARN finalize   path: '/home/vagrant/code/node_modules/.bufferutil.DELETE' }
npm WARN finalize Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modules/                                   .clean-css.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize  { [Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modu                                   les/.clean-css.DELETE']
npm WARN finalize   errno: -5,
npm WARN finalize   code: 'EIO',
npm WARN finalize   syscall: 'rmdir',
npm WARN finalize   path: '/home/vagrant/code/node_modules/.clean-css.DELETE' }
npm WARN finalize Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modules/                                   .cli-table.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize  { [Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modu                                   les/.cli-table.DELETE']
npm WARN finalize   errno: -5,
npm WARN finalize   code: 'EIO',
npm WARN finalize   syscall: 'rmdir',
npm WARN finalize   path: '/home/vagrant/code/node_modules/.cli-table.DELETE' }
npm WARN finalize Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modules/                                   .consolidate.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize  { [Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modu                                   les/.consolidate.DELETE']
npm WARN finalize   errno: -5,
npm WARN finalize   code: 'EIO',
npm WARN finalize   syscall: 'rmdir',
npm WARN finalize   path: '/home/vagrant/code/node_modules/.consolidate.DELETE'                                    }
npm WARN finalize Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modules/                                   .babylon.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize  { [Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modu                                   les/.babylon.DELETE']
npm WARN finalize   errno: -5,
npm WARN finalize   code: 'EIO',
npm WARN finalize   syscall: 'rmdir',
npm WARN finalize   path: '/home/vagrant/code/node_modules/.babylon.DELETE' }
npm WARN finalize Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modules/                                   .babel-plugin-transform-es2015-typeof-symbol.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize  { [Error: EIO: i/o error, rmdir '/home/vagrant/code/node_modu                                   les/.babel-plugin-transform-es2015-typeof-symbol.DELETE']
npm WARN finalize   errno: -5,
npm WARN finalize   code: 'EIO',
npm WARN finalize   syscall: 'rmdir',
npm WARN finalize   path: '/home/vagrant/code/node_modules/.babel-plugin-transfo                                   rm-es2015-typeof-symbol.DELETE' }

Various errors on renaming and removing directories. They don't look symlink related though, so it hints at a different error, something I've not seen before when mounting /home/vagrant/code without using NFS.

These are the mount_options I'm using in Homestead.yaml
mount_options: ['nolock', 'vers=3', 'udp', 'fsc', 'actimeo=1', 'intr']

Any ideas?

[jamesmacwhite]

It looks to be permissions related, but as vagrant up is started with Administrator, I'm struggling to understand why this would be.

[marcharding]

Can you share the package.json (or if it already fails with one package, the name of the package) so i can try to reproduce this?

[jamesmacwhite]

@marcharding npm_nfs_errno_minus_5.zip

Attached is the package.json and npm-shrinkwrap.json used in the project. In terms of specific packages, I've ran several npm i and errors seem to occur with different packages each run, but always syscall errors (errno -5) with rename and rmdir

I suspect its permissions related on the FS side, but as I don't get this behaviour with the standard shared folder setup, I'm not sure what route to explore, considering my VM is already elevated with "Run as administrator"

[marcharding]

Ok i think i know whats wrong, will take a few days to get fixed (probably sometime next week).

[jamesmacwhite]

@marcharding Cool. Appreciate you looking at the issue. Look forward to further info and a possible fix in the coming weeks.

Thanks.

[marcharding]

I though that the problem was npm deleting non empty directories (.staging), so i added a recursive delete function.

The rename/delete errors are gone but your sample package.json still fails with errors like these

npm ERR! tar.unpack untar error /home/vagrant/.npm/async/0.2.10/package.tgz
npm ERR! tar.unpack untar error /home/vagrant/.npm/async/0.2.10/package.tgz
npm ERR! tar.unpack untar error /home/vagrant/.npm/regenerate/1.3.1/package.tgz
npm ERR! tar.unpack untar error /home/vagrant/.npm/async/0.2.10/package.tgz
npm ERR! tar.unpack untar error /home/vagrant/.npm/async/0.2.10/package.tgz
npm ERR! tar.unpack untar error /home/vagrant/.npm/async/0.2.10/package.tgz
npm ERR! tar.unpack untar error /home/vagrant/.npm/yargs/4.8.1/package.tgz
npm ERR! tar.unpack untar error /home/vagrant/.npm/yargs/4.7.1/package.tgz
npm ERR! tar.unpack untar error /home/vagrant/.npm/request/2.73.0/package.tgz

I'm not sure whats going on, npm does so much stuff its hard to figure out whats fails. I can manually unpack the archives to the mounted folder just fine. Small npm install like npm install bower also work fine.

Googling for the npm ERR! tar.unpack untar error yields quite a few results without a specific solution.
I'm not really sure if this is maybe a bug in npm itself?

You can try yourself: WinNFSd.zip (this file is not production ready, just use it to do some tests)

[marcharding]

Ok, i do not think its an npm bug, i will try to figure out what is wrong...

[jamesmacwhite]

@marcharding Thanks for looking into this. I never saw those tar.unpack errors before. I guess my testing with npm i never got that far or yielded those errors.

Replacing the winnfsd.exe binary with the attached version (currently running vagrant-winnfsd 1.2.1, I did a rm -rf node_modules and reloaded vagrant with the NFS config again. Ran npm -i again and this what happened:

npm ERR! Linux 3.19.0-25-generic
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "i"
npm ERR! node v5.10.1
npm ERR! npm  v3.8.3
npm ERR! path /home/vagrant/code/node_modules/.staging/arr-diff-58f146f2
npm ERR! code EIO
npm ERR! errno -5
npm ERR! syscall rename

npm ERR! EIO: i/o error, rename '/home/vagrant/code/node_modules/.staging/arr-diff-58f146f2' -> '/home/vagrant/code/node_modules/arr-diff'
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /home/vagrant/code/npm-debug.log

On the finalize stage before I'd get lots of repeated errors, this time I only got one. I think specific packages seems to cause the errno -5, as re-running npm i each time yields different package that throw errno -5. One difference is rollbackFailedOptional now seems to be shown in the progress bar, don't believe it was before.

[marcharding]

Is /home/vagrant/ your mounted nfs folder or the native home directory?

[jamesmacwhite]

/home/vagrant is the home dir.

Actual mount within the VM is at /home/vagrant/code which mounts C:\Users\james.white\Projects\GitRepo with NFS to it. "GitRepo" being an example name for demonstration purposes.

[jamesmacwhite]

@marcharding Just wondering if you got any further on progress with the npm issues? Let me know if you need any further info or testing done.

[marcharding]

Not yet.

It would help if you can provide a much smaller package.json that fails.

[jamesmacwhite]

OK. Let me do some tests and see if there are specific deps that fail and create a smaller package.json

[jamesmacwhite]

The following packages seem to have problems:

lodash
grunt
grunticon-lib
yaml-loader
babel-core
babel-runtime

[marcharding]

Just wanted to give you an update that this issue will probably take some more time...

[jamesmacwhite]

No problem. Thanks for letting me know.

[strangedream1900]

This happened to me yesterday and before that it was working fine. I could not figure it out why. I'm running windows 10, maybe there was a windows update that caused winnfsd to stop working properly? The problem seems to be only on npm uninstall; npm install works fine. Sometimes there are also problems with files that need to be edited or rewritten(like with gulp running browserify(babelify) for example)

[jamesmacwhite]

@strangedream1900 Not the case for me, its been happening on Windows 10 1511 and 1607 (Anniversary update), I don't think a Windows Update is the problem here. It is however only certain npm packages that trigger it, others will install fine.

[strangedream1900]

@ jamesmacwhite I successfully installed lodash, grunt, babel-core, babel-runtime, yaml-loader. No problems there, but when I want to uninstall any package I get that npm ERR! errno -5... I'm running vagrant with admin privileges. I still think there was something windows did because before yesterday I had absolutely no problems(I updated to AU a week ago). Now I have 3 virtual machines with the same problem. If I have the time, I'm gonna try the same setup on windows 7.

[jamesmacwhite]

I'm running as admin as well for symlinks to work, otherwise npm fails horribly on the standard VBoxSF setup. I've never personally tried to uninstall with npm, I just nuke node_modules and let the package.json run through during testing.

I have no idea regarding Windows Update, personally I've had the problem for sometime and didn't think it was related to any Windows updates.

I guess if you can provide another usage case where the errno -5 occurs it might help debug further.

[strangedream1900]

So I just tested on an old windows 10 build and I get the same error. I also tested on an older version of my vagrant box, and also tried previous versions of vagrant-winnfsd..still the same. I ran out of ideas what it could be.
Hmm... it's quite bizarre, because it was working fine prior to yesterday.

[mariuszpass]

Any news on this issue?

[marcharding]

Not yet, i hope that i can get to this again in october.

[cedricroijakkers]

I have a permanent way to reproduce this issue, it's not in npm but while running a grunt job.

Each time I want to delete some files with a grunt-contrib-clean job, I get the following error:

Running "clean:beforebuild" (clean) task
ERROR
Warning: Unable to delete "target/" file (EIO: i/o error, rmdir 'target/'). Use --force to continue.

Deleting the files in directory target manually just works fine. I'm running Grunt on node v6.7.0.

I'm running:

• Ubuntu 16.04 guest in VirtualBox via Vagrant
• WinNFSd via the vagrant-winnfsd plugin
• Windows 10 version 1607 on the host

Edit:
I've updated WinNFSd to 2.3.0 (it was 2.2.0 in the vagrant plugin) and I still can reproduce the issue.

[marcharding]

@cedricroijakkers

can you provide me with the most simple grunt setup where this happens?

As for 2.3.0: This only had some fixes regarding the mount path, nothing really fancy...

[cedricroijakkers]

Here is my setup:

• Windows host with a directory exported, this directory contains a directory nfs-bug
• Linux guest with the exported directory mounted in /opt/hawaii

Inside the Linux guest, installed node.js v6.7.0 (Also installed the same node version in the Windows host, not really necessary, but I need it to be able to build anything because of this bug).

Most minimal grunt setup inside nfs-bug:

package.json:

{
  "devDependencies": {
    "grunt": "1.0.1",
    "grunt-contrib-clean": "1.0.0"
  }
}

Gruntfile.js:

module.exports = function (grunt) {
  grunt.initConfig({
    clean: {
      target: ["target/"],
    }
  });
  grunt.loadNpmTasks('grunt-contrib-clean');
  grunt.registerTask('default', ['clean:target']);
};

Now, at this point you need to cd into this directory, and run:
npm install

On my Linux guest, this sometimes fails horribly with the following examples:

npm ERR! Linux 4.4.0-31-generic
npm ERR! argv "/opt/node-v6.7.0-linux-x64/bin/node" "/opt/node/bin/npm" "install"
npm ERR! node v6.7.0
npm ERR! npm  v3.10.3
npm ERR! path ../coffee-script/bin/coffee
npm ERR! code EIO
npm ERR! errno -5
npm ERR! syscall symlink

npm ERR! EIO: i/o error, symlink '../coffee-script/bin/coffee' -> '/opt/hawaii/workspace/nfs-bug/node_modules/.bin/coffee'

Or:

npm WARN finalize Error: EIO: i/o error, rmdir '/opt/hawaii/workspace/nfs-bug/node_modules/.grunt-legacy-log-utils.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize  { Error: EIO: i/o error, rmdir '/opt/hawaii/workspace/nfs-bug/node_modules/.grunt-legacy-log-utils.DELETE'
npm WARN finalize     at Error (native)
npm WARN finalize   errno: -5,
npm WARN finalize   code: 'EIO',
npm WARN finalize   syscall: 'rmdir',
npm WARN finalize   path: '/opt/hawaii/workspace/nfs-bug/node_modules/.grunt-legacy-log-utils.DELETE' }

I've mostly seen it happen while doing a rmdir call, but sometimes also while doing a symlink call.

Either way, if you repeat the npm install a few times, after some tries it should finish and create a directory node_modules with all the dependencies you need. Alternatively, you can do the npm install under Windows, which always works.

Now for the issue I can permanently reproduce:

Create a directory target, and a file foo in there:

mkdir target
touch target/foo

And run the grunt clean task:

grunt

This always gives me:

Running "clean:target" (clean) task
ERROR
Warning: Unable to delete "target/" file (EIO: i/o error, rmdir 'target/'). Use --force to continue.

Aborted due to warnings.

Deleting the file and directory under target with a simple rm command always works. Moving the whole nfs-bug directory under a non-nfs mounted space also works. So it seems to me there is something going on with the rmdir, and as it seems also, but less frequently, symlink calls that node.js is doing is combination with nfs mounted directories exported on Windows.

[marcharding]

Please try the attached binary, i think that solves this (grunt task is working, npm install throws some errors but finishes). Thanks for the thorough report!

WinNFSd.zip

[patricknelson]

In almost all of these examples, I am noticing that it mostly involves the deletion of dotfiles (or directories) on the windows host. Is that the root of the issue here?

The symlink I'm not sure about, as I'm aware there are general issues with that when attempting to create from a Linux VM on a Windows host (regardless of vagrant share type), but I don't know.

[marcharding]

Did you try it again with the new binary linked above?

You can just replace the current one in %userprofile%\.vagrant.d\gems\gems\vagrant-winnfsd-1.3.0\bin

The deletion errors should be fixed with it, had nothing to do with dotfiles (i suspected that too) but with an implementation error for the remove nfs call.

[jamesmacwhite]

@marcharding Thanks for looking into this once again.

Would the attached binary resolve my originally reported issues with npm?

[marcharding]

@jamesmacwhite i'm not sure, would you mind trying again on your setup?

using the new binary above npm install with your files finished after quite some time (about 1 hour) but i still got the npm ERR! tar.unpack untar error erros.

fyi: npm install with your files does not finish successful on a native nfs mount (between two ubuntu machines). maybe it's a general npm problem with nfs mounts?

[mariuszpass]

@marcharding in my case, the new binary works well. All errors and warnings are gone. Thanks.

[cedricroijakkers]

@marcharding I have tested the new binary and it now works flawlessly, both with the "simple" version of Grunt I sent you, and also with the full suite we're running here. Thanks!

[marcharding]

@cedricroijakkers great 👍 thanks again for the thorough steps to reproduce this.

@jamesmacwhite, @patricknelson can you also test the new binary? if everything works out, i'll release a updated plugin.

[jamesmacwhite]

@marcharding Thanks for your work on this.

I've just got round to testing the new binary.

I've upgraded VirtualBox (5.1.6) and Vagrant (1.8.6) respectively as I was several versions behind and removed my node_modules folder completely for a full rebuild.

npm i use to hang for a while before starting, so this seems to be solved now. The good news is the errno -5 error appears to be fixed, which is awesome!

I did get a couple of "Operation not permitted" errors during the build which I haven't seen before on a previous version of the binary. It happened on specific npm packages bufferutil and utf-8-validate along with an exception thrown on ttf2woff2 during the build/make process. Not sure if you can debug anything from the output below.

npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher                                                     to avoid a RegExp DoS issue
npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher                                                     to avoid a RegExp DoS issue
npm WARN prefer global marked@0.3.5 should be installed with -g
npm WARN prefer global svgicons2svgfont@3.1.0 should be installed with -g
npm WARN prefer global node-gyp@2.0.2 should be installed with -g
npm WARN prefer global ttf2woff2@1.2.3 should be installed with -g

> bufferutil@1.2.1 install /home/vagrant/code/node_modules/bufferutil
> node-gyp rebuild

make: Entering directory `/home/vagrant/code/node_modules/bufferutil/build'
  CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
  SOLINK_MODULE(target) Release/obj.target/bufferutil.node
  COPY Release/bufferutil.node
cp: preserving permissions for ‘Release/bufferutil.node’: Operation not permitte                                                    d
make: *** [Release/bufferutil.node] Error 1
make: Leaving directory `/home/vagrant/code/node_modules/bufferutil/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_module                                                    s/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:100:13)
gyp ERR! stack     at ChildProcess.emit (events.js:185:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_proces                                                    s.js:204:12)
gyp ERR! System Linux 3.19.0-25-generic
gyp ERR! command "/usr/bin/nodejs" "/usr/lib/node_modules/npm/node_modules/node-                                                    gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/vagrant/code/node_modules/bufferutil
gyp ERR! node -v v5.10.1
gyp ERR! node-gyp -v v3.3.1
gyp ERR! not ok
npm WARN install:bufferutil@1.2.1 bufferutil@1.2.1 install: `node-gyp rebuild`
npm WARN install:bufferutil@1.2.1 Exit status 1

> utf-8-validate@1.2.1 install /home/vagrant/code/node_modules/utf-8-validate
> node-gyp rebuild

make: Entering directory `/home/vagrant/code/node_modules/utf-8-validate/build'
  CXX(target) Release/obj.target/validation/src/validation.o
  SOLINK_MODULE(target) Release/obj.target/validation.node
  COPY Release/validation.node
cp: preserving permissions for ‘Release/validation.node’: Operation not permitte                                                    d
make: *** [Release/validation.node] Error 1
make: Leaving directory `/home/vagrant/code/node_modules/utf-8-validate/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_module                                                    s/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:100:13)
gyp ERR! stack     at ChildProcess.emit (events.js:185:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_proces                                                    s.js:204:12)
gyp ERR! System Linux 3.19.0-25-generic
gyp ERR! command "/usr/bin/nodejs" "/usr/lib/node_modules/npm/node_modules/node-                                                    gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/vagrant/code/node_modules/utf-8-validate
gyp ERR! node -v v5.10.1
gyp ERR! node-gyp -v v3.3.1
gyp ERR! not ok
npm WARN install:utf-8-validate@1.2.1 utf-8-validate@1.2.1 install: `node-gyp re                                                    build`
npm WARN install:utf-8-validate@1.2.1 Exit status 1

> phantomjs@1.9.15 install /home/vagrant/code/node_modules/phantomjs
> node install.js

Downloading https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-1.9.8-linu                                                    x-x86_64.tar.bz2
Saving to /tmp/phantomjs/phantomjs-1.9.8-linux-x86_64.tar.bz2
Receiving...
  [===============================---------] 78% 0.0s
Received 12854K total.
Extracting tar contents (via spawned process)
Removing /home/vagrant/code/node_modules/phantomjs/lib/phantom
Copying extracted folder /tmp/phantomjs/phantomjs-1.9.8-linux-x86_64.tar.bz2-ext                                                    ract-1476192470466/phantomjs-1.9.8-linux-x86_64 -> /home/vagrant/code/node_modul                                                    es/phantomjs/lib/phantom
Writing location.js file
Done. Phantomjs binary available at /home/vagrant/code/node_modules/phantomjs/li                                                    b/phantom/bin/phantomjs

> ttf2woff2@1.2.3 install /home/vagrant/code/node_modules/ttf2woff2
> (node-gyp rebuild > builderror.log) || (exit 0)

../csrc/addon.cc: In function ‘void Convert(const v8::FunctionCallbackInfo<v8::V                                                    alue>&)’:
../csrc/addon.cc:32:38: error: ‘class v8::Object’ has no member named ‘GetIndexe                                                    dPropertiesExternalArrayDataLength’
   size_t input_length = inputBuffer->GetIndexedPropertiesExternalArrayDataLengt                                                    h();
                                      ^
../csrc/addon.cc:34:20: error: ‘class v8::Object’ has no member named ‘GetIndexe                                                    dPropertiesExternalArrayData’
       inputBuffer->GetIndexedPropertiesExternalArrayData());
                    ^
../csrc/addon.cc:49:70: error: conversion from ‘v8::MaybeLocal<v8::Object>’ to n                                                    on-scalar type ‘v8::Local<v8::Object>’ requested
   Local<Object> slowBuffer = node::Buffer::New(isolate, output_length);
                                                                      ^
make: *** [Release/obj.target/addon/csrc/addon.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_module                                                    s/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:100:13)
gyp ERR! stack     at ChildProcess.emit (events.js:185:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_proces                                                    s.js:204:12)
gyp ERR! System Linux 3.19.0-25-generic
gyp ERR! command "/usr/bin/nodejs" "/usr/lib/node_modules/npm/node_modules/node-                                                    gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/vagrant/code/node_modules/ttf2woff2
gyp ERR! node -v v5.10.1
gyp ERR! node-gyp -v v3.3.1
gyp ERR! not ok

> node-sass@3.7.0 install /home/vagrant/code/node_modules/node-sass
> node scripts/install.js

Binary downloaded and installed at /home/vagrant/code/node_modules/node-sass/ven                                                    dor/linux-x64-47/binding.node

> node-sass@3.7.0 postinstall /home/vagrant/code/node_modules/node-sass
> node scripts/build.js

"/home/vagrant/code/node_modules/node-sass/vendor/linux-x64-47/binding.node" exi                                                    sts.
 testing binary.
Binary is fine; exiting.

> pngquant-bin@3.1.0 postinstall /home/vagrant/code/node_modules/pngquant-bin
> node lib/install.js

  ✔ pngquant pre-build test passed successfully

> optipng-bin@3.1.1 postinstall /home/vagrant/code/node_modules/optipng-bin
> node lib/install.js

  ✔ optipng pre-build test passed successfully

> jpegtran-bin@3.0.6 postinstall /home/vagrant/code/node_modules/jpegtran-bin
> node lib/install.js

  ✔ jpegtran pre-build test passed successfully

> gifsicle@3.0.3 postinstall /home/vagrant/code/node_modules/gifsicle
> node lib/install.js

  ✔ gifsicle pre-build test passed successfully

[marcharding]

@jamesmacwhite Great 🎉

The permission stuff is not supported on nfs mounts (this is the case for not only winnfsd but native nfs mounts as well)

See nodejs/node-gyp#562 for more details.

There seem to be two possible solutions:

1: Using https://github.com/gael-ian/vagrant-bindfs with

config.vm.synced_folder ".", "/vagrant", type: :nfs
config.bindfs.bind_folder "/vagrant", "/vagrant"

(i'm not sure how that would solve this, but nevertheless its worth a try).

2: Change the "offending" command during the make process.
See nodejs/node-gyp#562 (comment)

[patricknelson]

@marcharding Hi -- I originally wasn't going to chime in since I believe my issue was unrelated. I ended up having the same bug again in the virtualbox share type as well, so I figured I should look elsewhere for a solution and not confuse or detract from the discussion. I think ultimately it had more to do with the length of the file path, for which I found a magic bullet for those of us on Windows (everyone here at least).

If the file path is too long (if that's the cause if your issue):

1. Use the subst command to shorten it, but more importantly, this allows you to easily ....
2. Alias to a path using the \\?\ prefix, which is a Windows Unicode workaround that allows for paths up to ~32k in length (surprisingly, and it works very well).

Example command:

subst x: "\\?\C:\super\long\path\here"

So that then even if you end up with x:\node_modules\inception\node_modules\ ad nauseam, you won't still be capped at the 260 char limit 😄

[jamesmacwhite]

@marcharding Many thanks for clarifying, I'll look at implementing a workaround for that specific component.

Looks like the originally reported issue is fixed now though, many thanks for your work on fixing this issue.

[marcharding]

@patricknelson thanks, i'll add this to the wiki.

Fixed with winnfsd 2.3.1, vagrant plugin will be updated soon.

[tmbdrogba]

@marcharding Any news about the update of the vagrant plugin ? :)

[jamesmacwhite]

@tmbdrogba I has been updated. The 1.3.1 release fixes this issue. Just run:

vagrant plugin update

[tmbdrogba]

@jamesmacwhite Thx for the answer. Things is, I have this version as well and still get the same error as you :s

[marcharding]

Try to provide a minimal package.json and i'll try to reproduce it.

[luckynum7]

Windows 10 pro, 1709, 16291.0
Vagrant 2.0.0 (installed with scoop)
vagrant-winnfsd 1.3.1
node v8.5.0 (installed with nodenv)
npm 5.3.0

Command:
npm install acorn, or yarn add acorn (acorn is used by babel-core)

Output:
npm install acorn

npm ERR! path ../acorn/bin/acorn
npm ERR! code EIO
npm ERR! errno -5
npm ERR! syscall symlink
npm ERR! EIO: i/o error, symlink '../acorn/bin/acorn' -> '/vagrant/node_modules/acorn-jsx/node_modules/.bin/acorn'

yarn add acorn

yarn add v1.1.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.1.2: The platform "linux" is incompatible with this module.
info "fsevents@1.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
error An unexpected error occurred: "EIO: i/o error, symlink '../acorn/bin/acorn' -> '/vagrant/node_modules/acorn-jsx/node_modules/.bin/acorn'".

[ivesdebruycker]

@luckynum7, this worked for me:

1. vagrant halt
2. kill process "winnfsd.exe" in task manager ("vagrant halt" doesn't stop winnfs daemon)
3. start vagrant in a shell with admin rights (winnfsd.exe will now have elevated privileges, making symlinking work)

Another solution if you don't want a shell with admin rights:

1. set winnfsd.exe to run as administrator
2. restart winnfsd.exe, e.g. by killing the process and restarting vagrant

Or you could allow non-admins to create symlinks, see https://superuser.com/questions/104845/permission-to-make-symbolic-links-in-windows-7 (not tested).

Also see #66

[leandrocrs]

@luckynum7 If you need to find where winnfsd is installed, open powershell and just type:

Get-Process winnfsd* | select Path

You can either pipe Stop-Process after selecting Id of winnfsd process

Get-Process winnfsd* | select Id | Stop-Process

[luckynum7]

Hi @ivesdebruycker and @leandrw, thanks for the tip 👍

[func0der]

This is still an issue. Can we reopen this?

I have the problem with webpack building.

[Firzenizer]

If anyone else is having trouble with just npm install, --no-bin-links might help. I was able to successfully run npm install --no-bin-links

[garethellis36]

The tip from @ivesdebruycker to allow non-admins to create symlinks worked for me:

Or you could allow non-admins to create symlinks, see https://superuser.com/questions/104845/permission-to-make-symbolic-links-in-windows-7 (not tested).

You will need administrator privileges to run gpedit.msc - I have a separate admin account that allowed me to do this. The SuperUser post notes that if the account you add to the list is an administrator, you will still need to be running with elevated privileges in the relevant context (i.e. winnfsd in this case).