df 还有空间，mkdir 却报 Disk quota exceeded：检查组配额

普通用户创建目录时收到 Disk quota exceeded，df 却显示大量剩余空间，换成 root 又能创建。这个组合需要查配额：整块文件系统还有容量，不代表当前用户或新文件所属的组仍有额度。root 能写也不能用来证明配额配置正确。

把配额查询对应到失败的目录

在实际失败的路径下检查，不要只看根分区。下面用 /srv/data 作为目标目录；查询身份时应使用执行失败写入的账号，而不是临时切换后的管理员账号。

id
findmnt --target /srv/data
df -h /srv/data
df -i /srv/data
quota -v

df -h 和 df -i 分别描述文件系统的容量和 inode，总量正常仍可能碰到用户、组或项目配额。quota -v 的结果还受本机工具、后端和查询权限影响；显示没有用户配额，不能直接排除其他类型。

确认目录及其父目录的属组、新建文件实际继承的组，再查询对应组。storage 是示例组名，应替换为失败写入实际涉及的组；查看其他组可能需要管理员权限。

ls -ld /srv/data
quota -vg storage

如果启用了项目配额，还要按该文件系统支持的工具查询目录所归属的项目。不要把 ext4 的配额启用步骤直接用于尚未确认类型的文件系统，也不要为了查一个错误修改挂载选项。

用户额度为空，组额度仍可能耗尽

一种需要留意的输出是：用户查询没有限制，组查询的块数却带 *，且超过 soft、hard 限额。例如组使用块数为 8971324*，soft 和 hard 都是 1048576；文件数为 43784，对应两个限额均为 0。

这组数字指向组的块配额，需要按工具输出的单位解释，不能直接当成字节或 GiB。文件数那一栏的 0 表示没有设置该项限额，不能把它读成“一个文件也不允许创建”。

硬限制会阻止继续分配；软限制还涉及宽限期。组配额由该组名下的文件共同消耗，同一组的其他账号可能已经用完额度。只统计当前用户自己的文件，容易漏掉这部分。

如果实际错误是 No space left on device，且 inode 已耗尽，应走文件系统 inode 排查。文件监听器的 ENOSPC 则要检查监听数量限制，它与这里的目录分配错误不同。

调整前先确认额度被谁占用

记录目标文件系统、写入账号、文件属组、当前用量与原限额。清理前确认组内数据归属和保留要求；有权限调整限额时，也应先确认底层实际容量和其他成员需求。

按批准的范围清理数据或调整对应主体的额度，然后重新查询配额，并通过同一个账号、同一个目录和正常业务入口复查写入。不要用关闭全部配额、给目录加 777 或把业务改成 root 来代替处理；这些操作既不能说明额度问题已经解决，也可能改变其他用户的约束。