Node.js：什么是 ENOSPC 错误以及如何解决？答案

【问题标题】：Node.js: what is ENOSPC error and how to solve?Node.js：什么是 ENOSPC 错误以及如何解决？
【发布时间】：2025-12-23 15:50:06
【问题描述】：

我在使用 Node.js 并将文件上传到服务器时遇到问题。为了将文件上传到服务器，我使用这个plugin。开始上传文件到服务器时，Node.js 进程崩溃并显示错误：

错误：ENOSPC。

服务器代码没有运行。

$ 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" 表示驱动器上没有空间，那么您将文件保存在哪里？或者 /tmp 已满？
我将文件保存在 /dev/xvda1 中。我可以制作 rm -rf /tmp/* 吗？
是的，但我认为 1mb 不足以用于文件上传，所以将 tmp-dir 更改为另一个位置，如 Blu Angel 的答案中
听起来您的用例可能有所不同，但 here's a great solution to this problem 来自另一个 SO 问题。
对于遇到此问题的任何人，check out this answer as well。使用 grunt 和 gulp 可以使用很多手表，所以这个答案详细说明了如何增加它。

标签： node.js

【解决方案1】：

运行以下命令以避免 ENOSPC：

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

对于 Arch Linux，将此行添加到 /etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288

然后执行：

sysctl --system

这也将在重新启动后持续存在。 Technical Details Source

【讨论】：

这就是它的作用。 github.com/guard/listen/wiki/…
不是随机数。每个使用的 inotify watch 占用 540 字节（32 位系统）或 1 kB（双 - 在 64 位系统上）。这来自不可交换的内核内存。因此，假设您将最大值设置为 524288，并且全部使用（不太可能），您将使用大约 524288。 256MB/512MB 32 位/64 位内核内存。
理论上没有最大值，只要你有足够的内存。在实践中，524288已经被应用官方推荐，人们一直将其设置为200万，并伴随着内存使用。
这帮助我解决了问题，这个链接github.com/guard/listen/wiki/… 包含所有详细信息。谢谢
有没有人觉得奇怪的是出来的错误只是ENOSPC？为什么没有像ENOSPC - no space on drive 这样的输出之后的描述？当然，一旦您知道错误代码的含义（Error NO SPaCe），错误代码就有意义了，但为什么不直接向用户提供这些信息呢？

【解决方案2】：

ENOSPC 表示驱动器上没有空间。

也许/tmp 已满？您可以通过设置npm config set tmp /path/to/some/other/dir 将npm 配置为使用不同的临时文件夹，或者删除/tmp 文件夹中的所有内容。

来源：npm 1.1.21 cannot write, ENOSPC 在 npm 的 github 仓库中。

请注意，我以上述来源中描述的方式解决了我的问题。不过看Murali Krishna's answer，更全面。

【讨论】：

我清理了 /tmp 文件夹并更改了 npm temp 文件夹，但遇到了同样的问题。 npm config get tmp show /vol/deploy/tmp
你能再展示一下你的输出吗？更改目录后得到的输出
events.js:71 throw arguments[1]; // Unhandled 'error' event Error: ENOSPC, write
你有错误监听器吗？如果不是写一个然后检查结果输出
错了，这个错误经常发生在开发人员工作区中，在观看文件时（通过 grunt / gulp）。这与一个进程可以观看多少个文件（本机观看）的 unix 限制有关。另一个答案（echo fs.inotify.max_user_watches=524288）是这些情况下的解决方案。

【解决方案3】：

解决我的问题的一个简单方法是：

npm cache clear

npm 或由它控制的进程正在查看太多文件。在构建节点上更新 max_user_watches 可以永远修复它。对于 debian，在终端上输入以下内容：

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

如果你想知道Increase the amount of inotify watchers如何，只需点击链接。

【讨论】：

我在创建文件.foreverignore 并将文件夹node_modules. 添加到它们时，使用forever, 解决了这个问题

【解决方案4】：

这不能归功于此，但@grenade 指出npm dedupe 将解决原因（文件太多）而不是症状。

来源：Grunt watch error - Waiting…Fatal error: watch ENOSPC。

【讨论】：

【解决方案5】：

重新启动机器为我解决了这个问题。我首先尝试擦除/tmp/，但节点仍在抱怨。

【讨论】：

重启后问题又出现了。做dedupe 有帮助。

【解决方案6】：

在 Linux 上，这可能是对文件监视数量的限制。

开发服务器使用inotify实现热重载。 inotify API 允许开发服务器监视文件并在文件更改时收到通知。

默认的 inotify 文件监视限制因发行版而异（Fedora 上为 8192）。开发服务器的需求经常超过这个限制。

最好的方法是尝试暂时增加文件监视限制，然后在您满意的情况下将其作为永久性配置更改。但请注意，这会改变整个系统的配置，而不仅仅是节点。

查看当前限制：

sysctl fs.inotify.max_user_watches

临时设置一个新的限制：

# 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

设置永久限制：

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

【讨论】：

【解决方案7】：

在 Ubuntu 18.04 上，我尝试了一个技巧，用来重新激活 ionic/node 监视的文件，它也可以在这里工作。这对于那些无法访问系统 conf 文件的人可能很有用。

CHOKIDAR_USEPOLLING=1 npm start

【讨论】：

这对于 CI 构建管道也非常有用，就像它们在 Docker 容器或其他 chroot 样式隔离下运行一样，您可能无法触及系统文件，而且它们只会触发“更改”，因为它们编译代码，他们实际上不会在需要热重载功能的地方编辑文件。

【解决方案8】：

如果您使用的是 VS Code，那么它应该无法在大型工作区中观看错误。

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

这表明 VS Code 文件观察程序的句柄已用完，因为工作区很大并且包含许多文件。可以通过运行查看电流限制：

cat /proc/sys/fs/inotify/max_user_watches

可以通过编辑/etc/sysctl.conf 并将此行添加到文件末尾来将限制增加到最大值：

fs.inotify.max_user_watches=524288

然后可以通过运行sudo sysctl -p 加载新值。

注意：524288 是观看文件的最大值。虽然您可以观看任何文件，但也建议您仅观看该限制。

【讨论】：

太棒了！反应很好，有据可查。一个++++
很高兴它有帮助！

【解决方案9】：

我解决了我杀死所有跟踪器控制进程的问题（如果你使用 GDM，你可以尝试，如果脚本在服务器上运行，显然不是你的情况）

tracker-control -r

我的设置：使用 GNOME 3 进行 Arch

【讨论】：

忘记指定了，是的，我遇到了同样的情况：Arch + GNOME

【解决方案10】：

如果您在 linux 文件系统上挂载的 /tmp 挂载为溢出（通常大小为 1MB），这可能是由于您未将 /tmp 指定为其自己的分区，并且您的根文件系统已填满，而 /tmp 被作为后备重新安装。

要在清除空间后解决此问题，只需卸载回退，它应该会重新安装到原来的位置：

sudo umount overflow

【讨论】：

【解决方案11】：

如果您在尝试运行ember server 命令时遇到此错误，请rm -rf tmp 目录。然后再次运行ember s。它帮助了我。

【讨论】：

【解决方案12】：

我遇到了同样的错误。当我运行 Reactjs 应用程序时。我所做的只是删除 node_modules 文件夹并再次键入并安装 node_modules。这消除了错误。

【讨论】：

这确实有效，为什么它被否决 - 这是问题所在。但它解决了问题，那你还需要什么？
不知道，可能是人们对我有一些个人问题。哈哈哈

【解决方案13】：

对我来说，我已经达到了用户可以拥有的最大文件数

用quota -s检查你的号码，文件下的号码不是太接近配额

【讨论】：

【解决方案14】：

这听起来很奇怪，但是是的，系统重启或killall node 为我解决了这个问题。

【讨论】：

【解决方案15】：

这表明 VS Code 文件观察程序的句柄已用完，因为工作区很大并且包含许多文件。手表的最大限制已达到，您可以通过运行查看限制：

cat /proc/sys/fs/inotify/max_user_watches

运行以下代码解决此问题：

fs.inotify.max_user_watches=524288

【讨论】：

【解决方案16】：

尝试了上面建议的大部分内容。最后删除 node_modules 目录对我有帮助。

所以我认为有效的是：

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
sudo sysctl --system
rm -r /tmp*（！！确保这不会对您造成任何破坏）
rm -r node_modules
Restart system

【讨论】：

如何在 Windows 系统中执行这些步骤，当我尝试运行 echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p 在 CMD 中，sys "sudo" 不被识别为命令

【解决方案17】：

就我而言，我这样做了

yarn cache clean

npm cache verify

rm -rf node_modules/

yarn install

【讨论】：

【解决方案18】：

在我的例子中，在 linux 上，sudoing 解决了这个问题。

例子：

sudo gulp dev

【讨论】：

这很危险！它可能成功了，因为一定比例的磁盘空间是为 root 保留的，这并没有解决核心问题 - 没有可用空间作为非特权用户（在目标位置）。
使用 sudo 是让事情发生的好方法，但大多数人忽略了理解使用 sudo 时发生的一切。特别是对于 npm 和 npm 模块，使用 sudo 可能会导致用户不希望由 root 执行的操作由 root 执行，例如文件创建或使用受保护的端口。基本上，在涉及 nvm/npm/node 的地方，“使用 sudo”的建议一文不值（也许是在跌跌撞撞地盯着太阳看了一会儿之后）。