“no space left on device”错误常因inode耗尽所致：df -h显示磁盘仍有几十gb空闲，但df -i显示inode使用率达100%，导致无法创建新文件或目录；因每个文件需唯一inode登记，耗尽后系统拒绝写入，与磁盘块空间无关。
磁盘空间明明还剩几十GB，保存文件时却弹出“No space left on device”或“磁盘空间不足”，这类问题不是看错了数字，而是系统在某个关键资源上真的“没位置登记”了——可能是inode耗尽、被删除但未释放的文件占着坑、临时目录写不进、挂载点被遮蔽，甚至只是root保留块卡住了普通用户。
第一步：确认到底是哪种“空间”满了
打开终端，依次运行两行命令：df -h 和 df -i。前者看数据块（你熟悉的“GB剩余”），后者看索引节点（inode）使用率。如果df -h显示还有12G，但df -i显示Use%是100%，那问题就锁定在inode——再多的磁盘容量也救不了，因为连创建新文件的“登记号”都发完了。
注意：【df -i必须和df -h一起看，单看df -h会彻底误判】。很多VPS用户就是只扫了一眼df -h，清完大文件仍报错，就是因为根本没查inode。
第二步：检查有没有“已删未放”的隐藏占位
执行lsof +L1。这个命令专门列出那些已被rm删除、但仍有进程在读写的文件。这类文件在磁盘上已不可见，但占用的空间不会释放，直到进程重启或关闭。
常见场景：Nginx/Apache日志被logrotate删掉，但主进程还在往旧fd里写；Docker容器持续输出日志后被删，但容器没重启；PHP-FPM子进程挂着临时session文件。只要看到输出结果，记下PID，执行kill -HUP PID（平滑重启）或直接kill PID（强制终止）就能立刻释放空间。
第三步：验证是否被小分区或挂载点遮蔽
方法一：用df -h /实际写入路径代替笼统的df -h。比如你在/home/wwwroot下保存文件报错，就运行df -h /home/wwwroot，而不是只看/根分区。有可能/home是单独挂载的小分区，只有2G，早就满了，而/根分区确实还有50G。
方法二：运行mount | grep " / "，检查是否有overlay、tmpfs、bind mount等覆盖了目标路径。某些Docker或安全加固配置会在/tmp或/var/tmp挂一个仅128MB的tmpfs，而Word或编译工具默认把临时文件写进去，一写就爆。
第四步：排查系统保留空间与权限陷阱
对ext4/ext3文件系统，运行tune2fs -l /dev/sda1 | grep "Reserved block count"（将/dev/sda1替换成你实际根分区设备）。默认保留5%空间给root用户专用，防止系统因磁盘满而崩溃。这意味着：即使df -h显示还有1.5G，但普通用户已无法写入——因为这1.5G全被划给root了。
临时绕过方法：用sudo -u root cp 文件 /目标路径测试是否能写入。若成功，说明就是保留块限制；长期解决可调低保留比例，如tune2fs -m 1 /dev/sda1（设为1%），但请确保服务器有稳定监控，避免root也写满导致系统瘫痪。
这一步操作起来很简单，直接把文件拖进去就行。
