node-gyp: Operation not supported error when using NFS mount

I get an error due to the use of flock in the ExecFlock function within gyp/pylib/gyp/mac_tool.py

chad$ npm install contextify
\
> contextify@0.1.11 install /path/to/shared/data/node_modules/contextify
> node-gyp rebuild

  CXX(target) Release/obj.target/contextify/src/contextify.o
  SOLINK_MODULE(target) Release/contextify.node
Traceback (most recent call last):
  File "./gyp-mac-tool", line 512, in <module>
    sys.exit(main(sys.argv[1:]))
  File "./gyp-mac-tool", line 28, in main
    exit_code = executor.Dispatch(args)
  File "./gyp-mac-tool", line 43, in Dispatch
    return getattr(self, method)(*args[1:])
  File "./gyp-mac-tool", line 216, in ExecFlock
    fcntl.flock(fd, fcntl.LOCK_EX)
IOError: [Errno 45] Operation not supported
make: *** [Release/contextify.node] Error 1
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:267:23)
gyp ERR! stack     at ChildProcess.emit (events.js:98:17)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:810:12)
gyp ERR! System Darwin 14.0.0
gyp ERR! command "node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /path/to/shared/data/node_modules/contextify
gyp ERR! node -v v0.10.33
gyp ERR! node-gyp -v v1.0.2
gyp ERR! not ok 
npm ERR! Darwin 14.0.0
npm ERR! argv "node" "/usr/local/bin/npm" "install" "contextify"
npm ERR! node v0.10.33
npm ERR! npm  v2.1.6
npm ERR! code ELIFECYCLE

I replaced ExecFlock with this recipe and it resolved the error. Unfortunately, the code is lgpl.v2.

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Reactions: 5
  • Comments: 39 (11 by maintainers)

Most upvoted comments

+1 Thanks @pkyeck!

Vagrantfile:

config.vm.synced_folder '.', '/vagrant', nfs: { mount_options: ['actimeo=2'] }
# Fix file permissions issues that will kill npm install on the Vagrant box.
config.bindfs.bind_folder '/vagrant', '/vagrant'

Host:

vagrant plugin install vagrant-bindfs
vagrant up

No more node-gyp errors when doing npm install on modules with native extensions. I spent 2 full days convinced the problem was with Ubuntu 14.04 LTS, libxmljs or node-gyp. It was just vagrant and NFS!

Any update on this? It seems the current state of the ticket:

  • the problem appears to be that node-gyp is executing cp -af (which fails on nfs mounts)
  • switching cmd_copy to ln -f $< $@ || cp -PRf $< $@ resolved the issue in at least one environment

Is there additional testing that needs to happen?

for all you vagrant users out there - I used https://github.com/gael-ian/vagrant-bindfs to fix the errors when trying to npm install on a NFS mount

For others dealing with packages that have this issue (I ran into it when trying to install the canvas package), I found that installing the package globally then linking it into my local (shared) project worked:

sudo npm install -g canvas
npm link canvas

I believe this works because installing the package globally puts it in a non-shared location where this issue doesn’t occur. Note that npm link uses a symlink so you may have issues with e.g. Linux guests on Windows hosts (I can never quite get that to work properly).

You can mount your NFS share with the noacl option in order to avoid this error.

Example (/etc/fstab): XXX.XXX.XXX.XXX:/remote/path /local/path nfs _netdev,auto,noacl 0 0

Possibly related. When we run npm install on a directory mounted with nfs we get this error:

make: Entering directory `/usr/local/src/v/node/node_modules/node-xmpp/node_modules/node-expat/node_modules/iconv/build'
  CC(target) Release/obj.target/libiconv/deps/libiconv/lib/iconv.o
  AR(target) Release/obj.target/iconv.a
  COPY Release/iconv.a
cp: preserving permissions for `Release/iconv.a': Operation not permitted
make: *** [Release/iconv.a] Error 1

node-gyp is doing a cp -af that is not supported over NFS.

Sad this was closed with no followup or fix.

  • Adding “noacl” as mentioned above did not fix it for me.
  • Performance issues when using “bindfs” which slows down all other file operations, such as “composer install”.
  • Ended up using the method above to do the “npm ci” in the /tmp folder and then move the results into the nfs destination. Still a performance impact but at least it only affects npm and I can decide to only do this for sites that have a dependency that needs node-gyp (in our case it is “ttf2woff2”)