Erreurs NPM lors de l'installation de packages sur un partage Windows

Ubuntu 12.10 est exécuté en tant qu'invité VMware sur mon hôte Windows 8.

J'ai partagé un dossier sur mon hôte Windows 8 et il est monté au démarrage de l'invité Ubuntu à l'aide de cette entrée dans fstab:

//myhost/work /work cifs credentials=/home/user/.smbcredentials,noserverino,nounix,uid=user,gid=user,file_mode=0777,dir_mode=0777 0 0 

Le partage fonctionne bien et peut être servi par un serveur Web tel que nginx.

Cependant, il semble y avoir des problèmes lorsque j'installe les paquets node.js à l'aide de npm, je reçois un tas d'erreurs comme celle-ci:

user@ubuntu:/work/test$ sudo npm install grunt
npm http GET https://registry.npmjs.org/grunt
npm http 304 https://registry.npmjs.org/grunt
...
npm ERR! error rolling back Error: ENOTEMPTY, rmdir '/work/test/node_modules/grunt/node_modules/lodash'
npm ERR! error rolling back  grunt@0.4.1 { [Error: ENOTEMPTY, rmdir '/work/test/node_modules/grunt/node_modules/lodash']
npm ERR! error rolling back   errno: 53,
npm ERR! error rolling back   code: 'ENOTEMPTY',
npm ERR! error rolling back   path: '/work/test/node_modules/grunt/node_modules/lodash' }
npm ERR! Error: UNKNOWN, symlink '../which/bin/which'
npm ERR! If you need help, you may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <npm-@googlegroups.com>

npm ERR! System Linux 3.5.0-26-generic
npm ERR! command "/usr/bin/node" "/usr/bin/npm" "install" "grunt"
npm ERR! cwd /work/test
npm ERR! node -v v0.10.0
npm ERR! npm -v 1.2.14
npm ERR! path ../which/bin/which
npm ERR! code UNKNOWN
npm ERR! errno -1
npm ERR! Error: ENOENT, chmod '/work/test/node_modules/grunt/node_modules/findup-sync/test/fixtures/aaa.txt'
npm ERR! If you need help, you may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <npm-@googlegroups.com>

npm ERR! System Linux 3.5.0-26-generic
npm ERR! command "/usr/bin/node" "/usr/bin/npm" "install" "grunt"
npm ERR! cwd /work/test
npm ERR! node -v v0.10.0
npm ERR! npm -v 1.2.14
npm ERR! path /work/test/node_modules/grunt/node_modules/findup-sync/test/fixtures/aaa.txt
npm ERR! fstream_path /work/test/node_modules/grunt/node_modules/findup-sync/test/fixtures/aaa.txt
npm ERR! fstream_type File
npm ERR! fstream_class FileWriter
npm ERR! fstream_finish_call chmod
npm ERR! code ENOENT
npm ERR! errno 34
npm ERR! fstream_stack /usr/lib/node_modules/npm/node_modules/fstream/lib/writer.js:305:19
npm ERR! fstream_stack Object.oncomplete (fs.js:93:15)
npm ERR! Error: ENOENT, lstat '/work/test/node_modules/grunt/node_modules/minimatch/test/basic.js'
npm ERR! If you need help, you may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <npm-@googlegroups.com>

npm ERR! System Linux 3.5.0-26-generic
npm ERR! command "/usr/bin/node" "/usr/bin/npm" "install" "grunt"
npm ERR! cwd /work/test
npm ERR! node -v v0.10.0
npm ERR! npm -v 1.2.14
npm ERR! path /work/test/node_modules/grunt/node_modules/minimatch/test/basic.js
npm ERR! fstream_path /work/test/node_modules/grunt/node_modules/minimatch/test/basic.js
npm ERR! fstream_type File
npm ERR! fstream_class FileWriter
npm ERR! code ENOENT
npm ERR! errno 34
npm ERR! fstream_stack /usr/lib/node_modules/npm/node_modules/fstream/lib/writer.js:284:26
npm ERR! fstream_stack Object.oncomplete (fs.js:93:15)
npm ERR! Error: ENOENT, lstat '/work/test/node_modules/grunt/node_modules/glob/test/00-setup.js'
npm ERR! If you need help, you may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <npm-@googlegroups.com>
...
npm ERR! not ok code 0
user@ubuntu:/work/test$ 

Qu'est-ce qui pourrait causer ce problème? En ligne de commande, je peux chmod, rmdirentre autres choses, utiliser sudo sans aucun problème.

Courir avec le --no-bin-linksfixe pour moi:

npm install --no-bin-links

--no-bin-linksdit npmde ne pas créer de lien symbolique. À ma connaissance, il n’existe aucun moyen de traduire des liens symboliques vers un partage Windows.

Comment autoriser la création de liens symboliques sur Windows, cette page m'a beaucoup aidé, ce qui explique que cela se produise même si votre dossier partagé est accessible en écriture.

Pour résoudre ce problème, vous devez activer la fonctionnalité des liens symboliques dans VirtualBox.

Exécuter à l'invite cmd:

VBoxManage setextradata YOURVMNAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/YOURSHAREFOLDERNAME 1

Puis vérifiez par:

VBoxManage getextradata YOURVMNAME enumerate

Si votre utilisateur appartient au groupe Administrateurs, démarrez VirtualBox avec "Exécuter en tant qu'administrateur"!

Par défaut, la stratégie de sécurité de Windows 7 n'autorise pas la création de liens symboliques car elle constitue une menace potentielle pour la sécurité. Exécutez "secpol.msc" et naviguez jusqu'à "Stratégies locales-Attribution des droits des utilisateurs" et ajoutez votre utilisateur à "Créer des liens symboliques". Je n’ai pas essayé cela, mais il se pourrait qu’après cela, la virtualbox puisse être exécutée en tant qu’utilisateur normal.

D'accord avec Lorem, mais ça ne suffit pas.

1. exécutez Virtualbox 'en tant qu'admininstrator' sous Windows.

2. assurez-vous que vous avez exécuté: VBoxManage.exe setextradata YOUR_VM BoxInternal2/SharedFoldersEnableSymlinksCreate/YOUR_SHARED_FOLDER 1

Remplacez YOUR_VM et YOUR_SHARED_FOLDER par vos valeurs. Vous pouvez vérifier la valeur via:VBoxManage.exe getextradata boot2docker-vm enumerate

Il y a un bogue de virtualbox qui suit ce problème.

Les versions les plus récentes de VirtualBox devraient autoriser les liens symboliques si vous démarrez VirtualBox en tant qu’administrateur (clic droit: Exécuter en tant qu’administrateur).

Il en va de même pour les boîtes vagabondes: il suffit d’exécuter votre cmd.exe / PowerShell en tant qu’administrateur et vous êtes prêt à partir.

Dans ce numéro ndr @drmyersii, donnez une excellente solution. Je ne ferai que copier et coller pour ne pas lier uniquement la réponse.

La vraie solution ici serait de configurer votre configuration pour autoriser les liens symboliques sur les hôtes Windows de votre fichier Vagrant. Voici un exemple (en supposant que vous l'exécutez dans VirtualBox):

config.vm.provider "virtualbox" do |v|
    v.customize ["setextradata", :id, "VBoxInternal2/SharedFoldersEnableSymlinksCreate/vagrant", "1"]
end

cela a bien fonctionné pour moi et je peux maintenant utiliser gulp avec scotchbox .

Pour moi, aucune de ces réponses n'a fonctionné. Je ne sais pas pourquoi mais je crois que c'est parce que ma part est NFS. Je ne pouvais donc pas le laisser autoriser les liens symboliques même en tant qu'administrateur et en modifiant les paramètres de setextradata. Je travaillais avec gulp et quelques autres paquets qui semblent avoir des problèmes d' obéissance à --no-bin-links. Il essayait TOUJOURS de créer des liens symboliques et échouait évidemment. Finalement, ce fil sur Github m'a amené à trouver une "solution", même si ça peut être. J'ai simplement installé le projet dans mon dossier non partagé et je l'ai défini comme étant mon NODEPATH.

export NODE_PATH=/home/vagrant/PROJECTNAME/node_modules

Le problème est que cela affectera tout le serveur et le processus de mise à jour / modification de l'emballage.