How to fix Error: ENOSPC: no space left on device (fs.watch ran out of capacity) in Node.js

Node.jsINTERMEDIATEHIGHUpdated Dec 9, 2025ยท 230 views

This error occurs when Node.js fs.watch() reaches the system limit on file descriptors or inode watchers. The file watching subsystem cannot monitor additional files because the system has exhausted its available watching capacity.

Quick fix

Fixes ENOSPC

cat /proc/sys/fs/inotify/max_user_watches
  1. Check current inotify limit on Linux
  2. Increase inotify watch limit permanently
  3. Optimize file watching in build tools
  4. Use file watch polling as fallback
node.js โ€” error
cat /proc/sys/fs/inotify/max_user_watches
Error: ENOSPC: no space left on device (fs.watch ran out of capacity)

What this error means

This error indicates that Node.js's fs.watch() function has exhausted the operating system's capacity to monitor file system changes. Unlike disk space issues, this refers to the system limit on inode watchers or file descriptor watches. On Linux systems, each watched file consumes a slot in the kernel's inotify watch limit (controlled by /proc/sys/fs/inotify/max_user_watches). When this limit is reached, fs.watch() fails with ENOSPC. On macOS and Windows, similar limitations exist through their respective file system event APIs (FSEvents and ReadDirectoryChangesW). This commonly occurs in development environments with build tools, IDE watchers, or applications monitoring large directory trees.

Typical symptoms

  • fs.watch() throws ENOSPC error when adding new file watchers
  • Build tools (webpack, vite, Next.js dev server) fail to start or freeze
  • IDE watchers stop working without error messages
  • Application crashes after watching a certain number of files
  • Error appears when running multiple watchers simultaneously
  • Problem occurs specifically on Linux systems first

Common causes

  1. Linux inotify watch limit (/proc/sys/fs/inotify/max_user_watches) is too low for the number of files being monitored
  2. Multiple Node.js processes or watchers all competing for the same system inotify limit
  3. Watching large project directories or node_modules with many nested files
  4. File watcher not properly cleaning up watches after deletion
  5. System-wide resource exhaustion from other applications also using inotify
  6. macOS or Windows file system event API hitting internal limits

How to fix "Error: ENOSPC: no space left on device (fs.watch ran out of capacity)"

1Check current inotify limit on Linux

First, verify what your current inotify watch limit is:

bash
cat /proc/sys/fs/inotify/max_user_watches

The default is typically 8192 on many distributions. If you see a low number (less than 10000), this is likely your issue.

2Increase inotify watch limit permanently

Increase the limit by editing the sysctl configuration:

bash
# Check current value
sudo sysctl fs.inotify.max_user_watches

# Set it to a higher value (e.g., 100000)
sudo sysctl -w fs.inotify.max_user_watches=100000

To make this permanent across reboots, add it to /etc/sysctl.conf:

bash
# Edit the sysctl configuration
sudo nano /etc/sysctl.conf

# Add or update this line
fs.inotify.max_user_watches=100000

# Apply the changes
sudo sysctl -p

For Docker/containerized environments:

dockerfile
RUN echo fs.inotify.max_user_watches=100000 | tee -a /etc/sysctl.conf

Or run the container with sysctls:

bash
docker run --sysctl fs.inotify.max_user_watches=100000 your-image
3Optimize file watching in build tools

Configure your build tools to watch fewer files or use polling instead of inotify:

webpack/webpack-dev-server:

javascript
// webpack.config.js
module.exports = {
  watchOptions: {
    ignored: ['node_modules', '.git', 'dist', 'build'],
    aggregateTimeout: 300,
    poll: false,
  },
};

Next.js:

javascript
// next.config.js
module.exports = {
  onDemandEntries: {
    maxInactiveAge: 25 * 1000,
    pagesBufferLength: 5,
  },
};

Vite:

javascript
// vite.config.js
export default {
  server: {
    watch: {
      ignored: ['node_modules', '.git', 'dist'],
      usePolling: false,
    },
  },
};

parcel:

javascript
// .parcelrc
{
  "watchIgnore": ["node_modules", ".git", "dist"],
}
4Use file watch polling as fallback

If increasing limits doesn't work, fall back to polling-based watching:

javascript
// For webpack
watchOptions: {
  poll: 1000, // Poll every 1000ms instead of using inotify
  aggregateTimeout: 300,
}

// For custom fs.watch usage
fs.watch(path, { recursive: true }, (eventType, filename) => {
  // Your handler
});

// Fallback pattern
const watcher = fs.watch(path, (eventType, filename) => {
  // Handler
});

watcher.on('error', (err) => {
  if (err.code === 'ENOSPC') {
    console.log('Falling back to fs.watchFile (polling)');
    fs.watchFile(path, { interval: 1000 }, (curr, prev) => {
      // Your polling handler
    });
  }
});

Polling is less efficient but works when inotify is exhausted.

5Reduce watched directories

Exclude unnecessary directories from watching:

javascript
// Generic watch with exclusions
function watchDirectory(dir, callback) {
  const ignoredDirs = new Set([
    'node_modules',
    '.git',
    '.next',
    'dist',
    'build',
    '.cache',
    'coverage',
    '.pytest_cache',
  ]);

  function watch(path) {
    const basename = require('path').basename(path);
    if (ignoredDirs.has(basename)) {
      return;
    }

    fs.watch(path, { recursive: true }, callback);
  }

  watch(dir);
}

For monorepos, only watch packages you're actively developing:

json
// In your lerna.json or package.json workspaces
{
  "workspaces": {
    "packages": ["packages/*/src"],
    "ignoreChanges": ["**/node_modules/**", "**/*.test.ts", "**/dist/**"]
  }
}
6Verify fix on macOS and Windows

macOS and Windows don't have the same inotify mechanism, but they have equivalent limitations:

macOS FSEvents:
The system has a limit on open file descriptors. Check and increase if needed:

bash
# Check soft limit
ulimit -n

# Increase soft limit for current session
ulimit -n 10240

# Make permanent (add to ~/.zshrc or ~/.bash_profile)
ulimit -n 10240

Windows ReadDirectoryChangesW:
Windows has a limit on change notifications per directory. If experiencing issues:
- Use polling via watchOptions poll flag
- Exclude unnecessary directories
- Reduce watch scope to specific file patterns

For all platforms, use the watchFile API as a fallback when watch fails:

javascript
const watchPath = (path, callback) => {
  fs.watch(path, callback).on('error', (err) => {
    if (err.code === 'ENOSPC' || err.code === 'EMFILE') {
      console.log('Using fs.watchFile fallback...');
      fs.watchFile(path, { interval: 1000 }, callback);
    }
  });
};

Advanced notes

Understanding inotify architecture: Linux's inotify system uses a single resource pool per user, not per process. If multiple Node.js processes, Docker containers, or IDE watchers run as the same user, they all share the same 8192 (or custom) watch limit. This is why monorepo development with multiple watchers often hits limits first.

Real-world examples:
- A typical Create React App project watches ~2000-3000 files
- A monorepo with 10 packages can watch 20,000+ files
- node_modules alone can contain 100,000+ files

Temporary overrides: You can also temporarily set limits for a single process:

bash
# Set limit for a specific process
prlimit --nofile=10240 --nproc=10240 npm start

Container memory: In Docker, inotify watches are still limited by the host system limits even if you set them in the container. The limit must be increased on the host or in compose/k8s configuration.

Monitoring watch usage: Debug which process is using watches:

bash
# Show inotify usage per process on Linux
find /proc -name wd_list -exec wc -l {} \;

# Or use lsof to see all watches
lsof | grep inotify

Performance consideration: Increasing max_user_watches to very high values (e.g., 1000000) can impact system performance. Balance between your needs and system resources. Typical production settings are 50000-100000.

Frequently asked questions

What does "ENOSPC" mean?
watch() function has exhausted the operating system's capacity to monitor file system changes. Unlike disk space issues, this refers to the system limit on inode watchers or file descriptor watches. On Linux systems, each watched file consumes a slot in the kernel's inotify watch limit (controlled by /proc/sys/fs/inotify/max_user_watches).
How do I fix "ENOSPC"?
This error occurs when Node.js fs.watch() reaches the system limit on file descriptors or inode watchers. The file watching subsystem cannot monitor additional files because the system has exhausted its available watching capacity.
What causes "ENOSPC"?
Linux inotify watch limit (/proc/sys/fs/inotify/max_user_watches) is too low for the number of files being monitored Multiple Node.js processes or watchers all competing for the same system inotify limit Watching large project directories or node_modules with many nested files
Is the "ENOSPC" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading