端口与体系
762 对应 IANA 登记的 quotad，是磁盘配额服务的注册端口。早期 Unix 系统上有独立的配额守护进程用于跨主机查询配额信息，这一登记就来自那个时期，实现方式与今天按文件系统参数管理配额的思路差别很大。
现在怎么做
配额管理如今通常直接在文件系统与目录服务层面配置：由文件系统或共享服务自身维护用户与目录的限额。独立提供配额查询的跨主机服务已经不多见。
基本信息
| 服务名称 | quotad（quota daemon） |
|---|---|
| 传输协议 | TCP 与 UDP |
| 用途 | 磁盘配额查询 |
| 所属体系 | 早期 Unix 配额服务 |
| 当前状态 | 历史实现 |
典型使用场景
- 配额管理方案梳理：比较独立配额服务与文件系统层配额
- 容量告警排障：用户空间不足时确认配额设置与实际使用量
- 老系统盘点：确认是否还有早期配额服务在运行
- 共享存储规划：多主机访问同一存储时配额由谁控制
- 扫描报告解读：扫描器标注 quotad，与实际进程比对
- 未知服务处置：无对应组件时按未知服务流程取证
定位与配额查看
定位与配额查看
# Linux：查看 762 的监听进程
ss -lntup 'sport = :762'
# 交叉验证可执行文件归属
sudo lsof -i :762
# 现代做法直接查看文件系统与配额使用情况
# repquota -s /home # 需要 root 权限
df -h /home 2>/dev/null配额管理方式对照
| 方式 | 控制位置 | 现状 |
|---|---|---|
| 文件系统层配额 | 挂载参数与配额文件 | 现代主流做法 |
| 独立配额服务 | 跨主机查询守护进程 | 历史实现 |
| 判读依据 | 挂载参数与配额文件 | 端口只反映早期实现思路 |
配额类问题往往不是“配置错误”，而是“配置没有生效”：文件系统挂载时未启用配额，后续设置就只是记录而未生效。排查时先确认挂载参数，再核对限制值。
共享存储环境里要明确配额由存储侧还是主机侧控制，两处同时设置且不一致时，用户看到的可用空间会与预期不符，排障极易走偏。