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

2 thoughts on “Error: Failed to flush to storage on DB Startup

  1. 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.

  2. 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.