Błędy Npm podczas instalowania pakietów w systemie Windows share

Mam Ubuntu 12.10 jako gość VMware na moim hoście Windows 8.

Udostępniłem folder na moim hoście Windows 8 i jest on instalowany w gościu Ubuntu podczas uruchamiania, używając tego wpisu w fstab:

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

Udział działa dobrze i może być obsługiwany przez serwer WWW, taki jak nginx.

Wydaje się jednak, że występują problemy podczas instalowania pakietów node.js przy użyciu npm, otrzymuję kilka takich błędów:

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  [email protected] { [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!     <[email protected]>

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!     <[email protected]>

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!     <[email protected]>

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!     <[email protected]>
...
npm ERR! not ok code 0
user@ubuntu:/work/test$ 

Co może być przyczyną tego problemu? Z wiersza poleceń, mogę chmod, rmdirmiędzy innymi z użyciem sudo bez żadnych problemów.

Uruchamianie z --no-bin-linksnaprawiłem to dla mnie:

npm install --no-bin-links

--no-bin-linksmówi, npmaby nie tworzyć żadnych dowiązań symbolicznych. Według mojej wiedzy nie ma sposobu na przetłumaczenie dowiązań symbolicznych na udział Windows.

Jak zezwolić na tworzenie dowiązań symbolicznych w systemie Windows, ta strona bardzo mi pomogła, co wyjaśnia, że ​​dzieje się tak, nawet jeśli folder współdzielony jest zapisywalny.

Aby to naprawić, musisz włączyć funkcję dowiązań symbolicznych w VirtualBox.

Uruchom w wierszu polecenia cmd:

VBoxManage setextradata YOURVMNAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/YOURSHAREFOLDERNAME 1

Następnie zweryfikuj przez:

VBoxManage getextradata YOURVMNAME enumerate

Jeśli twój użytkownik należy do grupy Administratorzy, uruchom VirtualBox z opcją „Uruchom jako administrator”!

Domyślnie zasady bezpieczeństwa systemu Windows 7 nie pozwalają na tworzenie dowiązań symbolicznych, ponieważ jest to potencjalne zagrożenie bezpieczeństwa. Uruchom „secpol.msc” i przejdź do „Lokalnych zasad - przypisań praw użytkownika” i dodaj użytkownika do „Utwórz dowiązania symboliczne”. Nie próbowałem tego, ale mogło być tak, że po tym virtualbox może być uruchamiany jako zwykły użytkownik.

Zgadzam się z lorem, ale to nie wystarczy.

1. uruchom Virtualbox „jako administrator” w systemie Windows.

2. upewnij się, że wykonałeś: VBoxManage.exe setextradata YOUR_VM BoxInternal2/SharedFoldersEnableSymlinksCreate/YOUR_SHARED_FOLDER 1

Zastąp YOUR_VM i YOUR_SHARED_FOLDER swoimi wartościami. Możesz sprawdzić wartość poprzez:VBoxManage.exe getextradata boot2docker-vm enumerate

Istnieje błąd Virtualbox śledzący ten problem.

Nowsze wersje VirtualBox powinny zezwalać na dowiązania symboliczne, jeśli uruchomisz VirtualBox jako administrator (kliknij prawym przyciskiem: Uruchom jako administrator).

To samo odnosi się do włóczęgów: po prostu uruchom swój cmd.exe / PowerShell jako administrator i możesz zacząć.

w tym numerze npm @drmyersii podaj świetne rozwiązanie, skopiuję i wkleję, aby nie linkować tylko odpowiedzi.

Prawdziwym rozwiązaniem byłoby skonfigurowanie konfiguracji w celu zezwalania na dowiązania symboliczne na hostach Windows w pliku Vagrantfile. Oto przykład (przy założeniu, że uruchamiasz go w VirtualBox):

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

działało to dla mnie świetnie, a teraz mogę korzystać z gulp w scotchbox .

Dla mnie żadna z tych odpowiedzi nie zadziałała. Nie jestem pewien dlaczego, ale wierzę, że to dlatego, że mój udział to NFS. Nie mogłem więc pozwolić, by zezwalał na dowiązania symboliczne, nawet gdy działał jako Administrator i zmieniał ustawienia setextradata. Pracowałem z gulp i kilkoma innymi pakietami, które wydają się mieć problemy ze słuchaniem --no-bin-links. Wciąż próbowałem stworzyć jakieś dowiązania symboliczne i oczywiście nie udało się. W końcu ten wątek na Github zlepił mnie w „rozwiązanie”, choć może być hackerskie. „Po prostu” zainstalowałem projekt w moim nieudostępnionym folderze i ustawiłem go jako NODEPATH.

export NODE_PATH=/home/vagrant/PROJECTNAME/node_modules

Zastrzeżenie polega na tym, że wpłynie to na cały serwer i przepływ pracy związany z aktualizacją / zmianą opakowania.