Node.js: what is ENOSPC error and how to solve?

Question

I have a problem with Node.js and uploading files to server. For uploading files to server I use this plugin. When starting file upload to the server, Node.js process crashed and show error:

Error: ENOSPC.

The server code doesn't run.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.9G  4.1G  3.5G  55% /
udev            288M  8.0K  288M   1% /dev
tmpfs           119M  168K  118M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            296M     0  296M   0% /run/shm
/dev/xvdf       9.9G  3.0G  6.5G  32% /vol
overflow        1.0M  1.0M     0 100% /tmp

"ENOSPC" means that there is no space on the drive, so where do you save your file? or maybe /tmp is full? — Jacob A., Mar 18 '14 at 10:03
yes, but i dont think 1mb is enough for fileuploads, so change the tmp-dir to another location like in the answer from Blu Angel — Jacob A., Mar 18 '14 at 10:15
Sounds like your use case might be different, but [here's a great solution to this problem](http://stackoverflow.com/questions/16748737/grunt-watch-error-waiting-fatal-error-watch-enospc) from another SO question. — Isaac Gregson, Apr 29 '15 at 15:42
For anyone stumbling across this, [check out this answer as well](http://stackoverflow.com/questions/16748737/grunt-watch-error-waiting-fatal-error-watch-enospc). Using grunt and gulp can use a lot of watches, so this answer details how to increase that. — Seiyria, Aug 28 '15 at 22:32
All in all, this is using the same solutions as in [Grunt watch error - Waiting…Fatal error: watch ENOSPC](http://stackoverflow.com/q/16748737/1983854) so probably worth marking this as a duplicate of that one. — fedorqui, Oct 13 '16 at 11:48
Update your accepted answer, the 2nd answer is the right one. — Lewis Diamond, Nov 15 '17 at 15:48

score 1393 · Accepted Answer · edited Feb 26 '19 at 07:18

1393

Run the below command to avoid ENOSPC:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

For Arch Linux add this line to /etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288

Then execute:

sysctl --system

This will also persist across reboots. Technical Details Source

edited Feb 26 '19 at 07:18

Blu

4,036
6
38
65

answered Sep 16 '15 at 06:10

Murali Krishna

14,253
2
13
15

32

Here is what it does. https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers#the-technical-details – Agus Syahputra Jun 18 '16 at 03:26
6

It's not a random number. Each used inotify watch takes up 540 bytes (32-bit system), or 1 kB (double - on 64-bit). This comes out of kernel memory, which is unswappable. So, assuming you set the max at 524288, and all were used (improbable), you'd be using approx. 256MB/512MB of 32-bit/64-bit kernel memory. – Murali Krishna Apr 05 '17 at 11:19
Theoretically there is no max value, as long as you have enough RAM. In practice, 524288 has been officially recommended by apps, and people have been setting it to 2 million, with the accompanying memory usage. – Murali Krishna Apr 05 '17 at 11:23
This has helped me to solve the problem also this link https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers#the-technical-details has all the details. Thanks – amitsin6h Jun 13 '19 at 16:10
Does anyone else find it strange that the error that comes out is simply `ENOSPC`? Why not have a description right after the output like `ENOSPC - no space on drive`? Sure, the error code makes sense once you know what it means (**E**rror **NO** **SP**a**C**e), but why not just give users that info up front? – Shadoninja Jun 21 '19 at 15:16
Don't no what happens after running this command, but it works for me!! Thanks @MuraliKrishna – Sanjaysinh Zala Mar 13 '20 at 06:06
On Ubuntu, you can put this setting in a separate file in `/etc/sysctl.d`: `echo fs.inotify.max_user_watches=524288 | sudo tee /etc/sysctl.d/60-inotify.conf && sudo sysctl --system` – Jo Liss Jul 07 '20 at 22:20
How can I run the command in windows? – sarbashis Dec 10 '21 at 16:39

Blu · Answer 2 · 2020-08-31T06:06:13.920

86

ENOSPC means that there is no space on the drive.

Perhaps /tmp is full? You can configure npm to use a different temp folder by setting npm config set tmp /path/to/some/other/dir, or maybe delete everything out of the /tmp folder.

Source: npm 1.1.21 cannot write, ENOSPC in npm's repo in github.

Note I solved my problem in the way that described in above source. However, see Murali Krishna's answer, which is more comprehensive.

edited Aug 31 '20 at 06:06

answered Mar 18 '14 at 10:10

Blu

4,036
6
38
65

I cleaned /tmp folder and changed npm temp folder, but have the same problem. `npm config get tmp` show /vol/deploy/tmp – Giffo Mar 18 '14 at 10:30
can you show your out put again ? output that you get After change dir – Blu Mar 18 '14 at 10:40
`events.js:71 throw arguments[1]; // Unhandled 'error' event Error: ENOSPC, write` – Giffo Mar 18 '14 at 10:47
1

do you have error listener ? if not than write one and then check resulted output – Blu Mar 18 '14 at 10:52
in your code are you assign `true` or `false` to `debug`? if `false` than make it `true` so all server response will print on console – Blu Mar 18 '14 at 10:59
I had this happen to me even when tmp was mounted on root filesystem and I still had 7 gigs of space left. However I deleted everything at tmp, and it all started working again. How can this be so? – CMCDragonkai Oct 08 '14 at 06:16
76

wrong, this error happens often in developer workspaces when watching files (via grunt / gulp). This has to do with a unix limit of how many files a process can watch (native watch). The other answer (echo fs.inotify.max_user_watches=524288) is the solution in those cases. – cancerbero Oct 16 '15 at 23:13
@cancerbero that's a much better explanation than the accepted answer. i'd rather know what's going on and potentially adjust my workflow instead of blindly throwing unexplained system config changes at my OS – worc Apr 18 '18 at 19:35
No, my drive has enough space. – kiltek Jun 06 '18 at 10:04

score 33 · Answer 3 · answered Nov 09 '18 at 07:32

33

A simple way that solve my problem was:

npm cache clear

npm or a process controlled by it is watching too many files. Updating max_user_watches on the build node can fix it forever. For debian put the following on terminal:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

If you want know how Increase the amount of inotify watchers only click on link.

answered Nov 09 '18 at 07:32

Danrley Pereira

1,126
14
22

2

I have that problem with `forever,` fixed it when I create the file `.foreverignore` and add to them folder `node_modules.` – Vilintritenmert Mar 07 '19 at 08:39
my problem is on pipeline, `node_modules` is already on `.gitIgnore`. – Adi Prasetyo Feb 15 '23 at 17:05

score 28 · Answer 4 · edited May 23 '17 at 12:10

28

Can't take credit for this, but @grenade pointed out that npm dedupe will fix the cause (too many files) and not the symptom.

Source: Grunt watch error - Waiting…Fatal error: watch ENOSPC.

edited May 23 '17 at 12:10

Community

1
1

answered Nov 05 '15 at 18:59

orbiteleven

951
1
11
21

score 9 · Answer 5 · answered May 23 '19 at 10:00

9

On Ubuntu 18.04 , I tried a trick that I used to reactivate the file watching by ionic/node, and it works also here. This could be useful for those who don't have access to system conf files.

CHOKIDAR_USEPOLLING=1 npm start

answered May 23 '19 at 10:00

Manolo de la Vega

183
1
9

1

This can also be really useful for CI build pipelines as if they run under Docker containers or other chroot style isolation you probably can't touch the system files, plus they are only triggering "changes" as they compile the code, they won't be actually editing files where it needs a hot reload functionality. – dragon788 Apr 14 '21 at 16:26

score 9 · Answer 6 · answered Jan 14 '20 at 00:43

On Linux, this is likely to be a limit on the number of file watches.

The development server uses inotify to implement hot-reloading. The inotify API allows the development server to watch files and be notified when they change.

The default inotify file watch limit varies from distribution to distribution (8192 on Fedora). The needs of the development server often exceeds this limit.

The best approach is to try increasing the file watch limit temporarily, then making that a permanent configuration change if you're happy with it. Note, though, that this changes your entire system's configuration, not just node.

To view your current limit:

sysctl fs.inotify.max_user_watches

To temporarily set a new limit:

# this limit will revert after reset
sudo sysctl fs.inotify.max_user_watches=524288
sudo sysctl -p
# now restart the server and see if it works

To set a permanent limit:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

score 8 · Answer 7 · answered Oct 24 '17 at 12:11

8

Rebooting the machine solved the problem for me. I first tried wiping /tmp/ but node was still complaining.

answered Oct 24 '17 at 12:11

Bjorn Reppen

22,007
9
64
88

The problem came back after rebooting . Doing `dedupe` helped. – Parnab Sanyal Nov 29 '18 at 19:02

score 6 · Answer 8 · answered Jul 06 '20 at 05:46

If you're using VS Code then it'll should unable to watch in large workspace error.

"Visual Studio Code is unable to watch for file changes in this large workspace" (error ENOSPC)

It indicates that the VS Code file watcher is running out of handles because the workspace is large and contains many files. The current limit can be viewed by running:

cat /proc/sys/fs/inotify/max_user_watches

The limit can be increased to its maximum by editing /etc/sysctl.conf and adding this line to the end of the file:

fs.inotify.max_user_watches=524288

The new value can then be loaded in by running sudo sysctl -p.

Note: 524288 is the max value to watch the files. Though you can watch any no of files but is also recommended to watch upto that limit only.

Excellent! Great response, well-documented. A++++ – kmiklas Jul 27 '20 at 04:57 — kmiklas, Jul 27 '20 at 04:57

score 2 · Answer 9 · edited Oct 13 '16 at 11:37

2

If your /tmp mount on a linux filesystem is mounted as overflow (often sized at 1MB), this is likely due to you not specifying /tmp as its own partition and your root filesystem filled up and /tmp was remounted as a fallback.

To fix this after you’ve cleared space, just unmount the fallback and it should remount at its original point:

sudo umount overflow

edited Oct 13 '16 at 11:37

fedorqui

275,237
103
548
598

answered Jan 08 '15 at 08:44

Pradeep Kumar

33
6

score 2 · Answer 10 · edited Oct 13 '16 at 11:37

2

I solved my problem killing all tracker-control processes (you could try if you use GDM, obviously not your case if the script is running on a server)

tracker-control -r

My setup: Arch with GNOME 3

edited Oct 13 '16 at 11:37

fedorqui

275,237
103
548
598

answered Mar 06 '16 at 15:27

Denys Vitali

530
6
19

1

Forgot to specify it, yep, I was in the same situation: Arch + GNOME – Denys Vitali Mar 23 '16 at 15:32

score 2 · Answer 11 · answered Mar 22 '17 at 21:28

2

If you encounter this error during trying to run ember server command please rm -rf tmp directory. Then run ember s again. It helped me.

answered Mar 22 '17 at 21:28

Daniel Kmak

18,164
7
66
89

score 2 · Answer 12 · answered Nov 30 '18 at 10:23

2

I was having Same error. While I run Reactjs app. What I do is just remove the node_modules folder and type and install node_modules again. This remove the error.

answered Nov 30 '18 at 10:23

Ghayyas Mubashir

138
1
7

this really works, why is it downvoted - it is the question. But it solves the problem, so what you need else? – Alexey Nikonov Jun 25 '19 at 15:35
2

Don't know, May be peoples have some personal issue with me. hahaha – Ghayyas Mubashir Jul 01 '19 at 09:05
I haven't voted on this answer, but it doesn't provide any explanation as to _why_ removing node_modules solves the problem, and that makes it a poor answer in my view. As a programmer I want to understand the root cause of problems rather than blindly applying workarounds. – snakecharmerb Oct 06 '22 at 13:42

score 1 · Answer 13 · answered Jul 21 '16 at 14:09

1

For me I had reached the maximum numbers of files a user can own

Check your numbers with quota -s and that the number under files is not too close to the quota

answered Jul 21 '16 at 14:09

neric

3,927
3
21
25

score 1 · Answer 14 · answered Dec 03 '21 at 13:38

1

Tried most of the things suggested above. At the end deleting node_modules directory helped me.

So I think what worked is:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
sudo sysctl --system
rm -r /tmp* (!! make sure this will not break anything for you)
rm -r node_modules
Restart system

answered Dec 03 '21 at 13:38

Shubham Jain

876
1
9
17

How to perform these steps in windows system, when I tried to run echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p in CMD, it sys "sudo" is not recognized as command – sarbashis Dec 10 '21 at 06:38

score 0 · Answer 15 · answered Sep 10 '20 at 15:44

It indicates that the VS Code file watcher is running out of handles because the workspace is large and contains many files. The max limit of watches has been reacherd, you can viewed the limit by running:

cat /proc/sys/fs/inotify/max_user_watches

run below code resolve this issue:

fs.inotify.max_user_watches=524288

score 0 · Answer 16 · edited Dec 15 '21 at 13:09

0

In my case, I did this

yarn cache clean

npm cache verify

rm -rf node_modules/

yarn install

edited Dec 15 '21 at 13:09

Dharman

30,962
25
85
135

answered Dec 15 '21 at 13:03

Nicolas

2,684
1
16
22

score -19 · Answer 17 · answered Aug 02 '15 at 06:43

-19

In my case, on linux, sudoing fixed the problem.

Example:

sudo gulp dev

answered Aug 02 '15 at 06:43

Sebastien Chartier

130
1
3

6

This is dangerous! It likely succeeded because a certain percentage of disk space is reserved for root, which doesn't address the core problem – no space available as the unprivileged user (at the target location). – Liam Dawson Aug 31 '15 at 04:04
Using sudo is a great way to make things happen, but most people neglect to understand everything that happens when sudo is used. Particularly with npm, and npm modules, using sudo can result in things being performed by root which the user doesn't want to have be performed by root, such as file creation or use of protected ports. Basically, the "use sudo" advice falls flat on its face (perhaps after stumbling and staring into the sun for a moment) where nvm/npm/node is concerned. – bschlueter Aug 01 '16 at 22:43

Node.js: what is ENOSPC error and how to solve?

17 Answers17

Linked

Related