Error: Failed to flush to storage on DB Startup

I’m running a project inside a vagrant box and get this error on the app startup.

Linux vagrant-ubuntu-trusty-64 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

vagrant@vagrant-ubuntu-trusty-64:/vagrant/alurapic$ npm start

alurapic@1.0.0 start /vagrant/alurapic node server.js

Banco data.db pronto para uso Servidor escutando na porta: 3000 /vagrant/alurapic/node_modules/nedb/lib/datastore.js:77 if (err) { throw err; } ^

Error: Failed to flush to storage at /vagrant/alurapic/node_modules/nedb/lib/storage.js:63:19 at FSReqWrap.oncomplete (fs.js:82:15)

npm ERR! Linux 3.13.0-79-generic npm ERR! argv “/usr/bin/nodejs” “/usr/bin/npm” “start” npm ERR! node v4.3.2 npm ERR! npm v2.14.12 npm ERR! code ELIFECYCLE npm ERR! alurapic@1.0.0 start: node server.js npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the alurapic@1.0.0 start script ‘node server.js’. npm ERR! This is most likely a problem with the alurapic package, npm ERR! not with npm itself. npm ERR! Tell the author that this fails on your system: npm ERR! node server.js npm ERR! You can get their info via: npm ERR! npm owner ls alurapic npm ERR! There is likely additional logging output above. npm ERR! Linux 3.13.0-79-generic npm ERR! argv “/usr/bin/nodejs” “/usr/bin/npm” “start” npm ERR! node v4.3.2 npm ERR! npm v2.14.12 npm ERR! path npm-debug.log.554385b17e09696d528b9176a40549ad npm ERR! code ETXTBSY npm ERR! errno -26 npm ERR! syscall rename

npm ERR! ETXTBSY: text file is busy, rename ‘npm-debug.log.554385b17e09696d528b9176a40549ad’ -> ‘npm-debug.log’ 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! /vagrant/alurapic/npm-debug.log

[cmgriffing]

I realize this is a closed issue, but it is the highest ranked search result for this problem.

For the sake of anyone finding this through Google, I was able to fix this issue in my own environment by making sure that vagrant synced the folder using NFS.

[ericblade]

I recognize that this is old, but … yeah. Not an internal node problem. You simply can’t fsync on some types of file systems.

It would be a correct solution, if this is triggered via calls to watch, to catch the EINVAL error, and either take the alternative route (watch via poll), or just not watch.