如果挂载时没有明确写上rw，或者fstab本身配置有误，文件系统就很容易直接变成只读状态。遇到这种情况，先看一眼mount的输出基本就能定位问题，然后把fstab里options字段改成defaults,rw这类正确配置即可；另外，像NTFS、FAT这类非原生文件系统本身并不支持chmod，权限不能靠后期修改，必须在挂载时通过uid、gid、umask等参数来控制。
挂载时没加 rw，或者挂载后权限被覆盖，文件系统就默认只读——这不是 chmod 能解决的，得从挂载机制和文件属主两层入手。
挂载选项里漏了 rw，mount 命令不生效
直接执行 sudo mount -o rw /dev/sdb1 /mnt/data 只对当前会话有效；如果设备在 /etc/fstab 里用的是 ro 或没显式声明 rw，重启或 mount -a 后仍只读。
defaults本身包含rw，但某些文件系统（如 NTFS、exFAT）或内核版本下可能不生效，必须显式写rw- 检查当前挂载状态：
mount | grep /mnt/data，看输出里有没有rw；若显示ro，说明挂载参数没生效 - 修改
/etc/fstab对应行，在第四列（options）中确保含rw，例如：UUID=xxx /mnt/data ntfs-3g defaults,rw,uid=1000,gid=1000,umask=022 0 0 - 改完后先
sudo umount /mnt/data，再sudo mount -a，避免旧挂载残留
chmod 和 chown 对挂载点目录无效？可能是文件系统类型限制
NTFS、FAT32、exFAT 等非 Linux 原生文件系统不支持 POSIX 权限模型，chmod 改不了实际读写能力，只能靠挂载参数控制。
- 对 NTFS 分区，必须用
ntfs-3g挂载，并通过uid、gid、umask控制用户访问，例如：umask=022表示所有者可读写，组和其他人可读 - ext4/btrfs 等原生文件系统才真正响应
chmod；但注意：挂载点目录本身的权限（如/mnt/data）不影响其下文件——那是挂载后文件系统的元数据决定的 - 常见误操作：
sudo chmod 777 /mnt/data后仍无法写入，本质是底层文件系统未授权，不是目录权限问题
umask 值设错导致新建文件不可写
即使挂载为 rw，新建文件也可能因 umask 过严而缺写权限，尤其在共享挂载点上容易踩坑。
umask=000→ 新建文件默认666（所有者/组/其他人全可写），umask=022→ 默认644（仅所有者可写）- 对需要协作写的场景（如 Web 服务器上传目录），挂载时加
umask=002更合理：uid=www-data,gid=www-data,umask=002 umask只影响新建文件，已有文件需单独chmod；且它不改变已存在的目录权限，只是后续创建行为的模板
权限冲突：挂载参数 + 目录属主 + 文件系统原生权限三者叠加
最终能否写入，是挂载选项、挂载点目录属主、以及底层文件系统自身权限三者共同作用的结果，任一环节卡住都会失败。
- 挂载点目录（如
/mnt/data）本身要有执行权限（x）才能进入——chmod 755 /mnt/data是基础 - 挂载后，
ls -ld /mnt/data显示的权限是挂载点目录的，不是挂载内容的；真正起作用的是挂载后ls -l /mnt/data/file.txt的输出 - 若挂载的是 ext4，且你有该分区的 root 权限，可进挂载点后用
sudo chown -R $USER:$USER /mnt/data彻底接管；但 NTFS 不支持，强行 chown 会报错或静默忽略 - 最隐蔽的坑：某些 USB 设备自动挂载时用了
noexec,nosuid,nodev等限制项，光加rw不够，得一并清理或覆盖
真正要改读写权限，得先分清是挂载机制问题还是文件系统权限问题；混用 chmod 和挂载参数，反而会让权限逻辑更混乱。非原生文件系统上，挂载参数才是唯一可靠入口。
