最直接方式是运行mount命令并检查输出中是否含ro；有ro即只读，含rw且无ro即读写，需注意空格精准匹配挂载点以避免误判。
用 mount 命令看挂载点是否只读
最直接的方式是运行 mount，它会列出所有已挂载文件系统及其选项。关键看输出里有没有 ro（read-only）——有就是只读，没出现 ro 且含 rw 就是可读写。
常见错误现象：明明 ls -l 显示目录有 w 权限，但 touch test.txt 却报 Read-only file system。这时问题不在文件权限，而在挂载选项。
-
mount | grep "/dev/sda1"—— 精准过滤某块设备的挂载状态 -
mount | grep " /mnt/data "—— 注意空格，匹配挂载路径（前后加空格避免误匹配子串） - 输出中若含
(rw,relatime)或(rw,seclabel)，说明是读写挂载；若为(ro,errors=remount-ro)，则确认只读
用 lsblk -o NAME,MOUNTPOINT,FSTYPE,RO 快速扫全盘
lsblk 的 -o RO 列比 mount 更直观：值为 1 表示该块设备（或其分区）被标记为只读，0 表示可写。注意：这个 RO 是内核层面的只读标志，可能来自硬件开关、BIOS设置或挂载时强制指定。
容易踩的坑：RO=0 不代表一定能写——比如文件系统损坏后，内核可能自动 remount 为 ro，此时 lsblk 仍显示 0，但 mount 输出已变成 ro。所以必须交叉验证。
-
lsblk -o NAME,MOUNTPOINT,FSTYPE,RO,SIZE—— 一次性看清设备、挂载点、类型、只读状态和容量 - 对 NVMe 设备，
NAME可能是nvme0n1p2，别漏掉末尾的pX分区号 - 如果
MOUNTPOINT为空，说明该分区未挂载，RO列无实际意义
为什么 df -hT 不能直接判断读写权限
df -hT 能看到文件系统类型（如 ext4、xfs）和使用率，但它**不显示挂载选项**。同一块磁盘，可以 mount -o ro /dev/sdb1 /mnt 只读挂载，也可以 mount -o rw /dev/sdb1 /mnt 读写挂载——df 输出完全一样。
典型误判场景：运维同学看到 df 显示 /dev/sdb1 挂在 /data 下，就默认可写，结果应用写入失败。根源是忽略了挂载时加了 -o ro 或 defaults,ro。
-
df -hT /data只告诉你挂在哪、什么类型、剩多少空间，不告诉你“能不能写” - 想确认读写能力，必须回到
mount或findmnt（findmnt /data更精准，直接查某路径） - 某些容器环境（如 Docker volume bind mount），宿主机
df看到的是底层存储，但容器内挂载可能是ro，需进容器再跑mount
cat /proc/mounts 和 findmnt 的适用差异
/proc/mounts 是内核实时挂载表的原始 dump，字段多但不易读；findmnt 是封装好的工具，支持按路径、设备、类型过滤，更贴近日常排查习惯。
性能与兼容性影响：findmnt 在较新系统（util-linux ≥ 2.20）默认可用；老系统（如 CentOS 6）可能没有，得靠 grep + /proc/mounts。
-
findmnt -t ext4—— 查所有 ext4 类型挂载点 -
findmnt -D /dev/sdc1—— 查该设备挂在哪（-D匹配源设备） -
grep " /mnt/backup " /proc/mounts | awk '{print $4}'—— 提取挂载选项字段，人工检查是否含ro
ro，一切写操作都会失败。重点不是看谁有权限，而是看“这块磁盘此刻是不是被系统锁死了写入口”。
