nedb: 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

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 16 (1 by maintainers)

Most upvoted comments

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.

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.

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.

Any plans on nedb to correct the logic and have a container viable version? I have read the comments on setting up custom storage properties to get around this with nfs, but that is enough of a hassle that most devs will just move on and use something else.

Anyone ever figure this out when having the issue with Docker for Windows? I see that @cmgriffing got it to work with using NFS on vagrant, anyway to do the same in docker?