虚拟机chmod 755不生效、文件仍不可读，通常不是chmod命令写错了，而是文件系统挂载方式、SELinux/AppArmor、ACL、UID映射或父目录权限在更底层拦截。
虚拟机chmod 755权限不生效怎么办？先排查这五类原因
在Linux里，chmod修改的是inode上的mode权限位，据Linux man-pages，chmod系统调用改变的是文件模式，但内核最终放行读取，还要看挂载选项、安全模块和ACL，也就是说，755只是“名义权限”，不等于“实际可读”。
多数情况下,问题集中在下面几类：
- 文件系统本身不支持POSIX权限，比如FAT32、exFAT。
- 挂载时用了只读、
noperm、noacl等选项。 - SELinux或AppArmor安全上下文拦住了读取。
- ACL的mask把有效权限压低了。
- 父目录缺少执行权限,或者容器内外UID不一致。
为什么Linux虚拟机chmod后文件仍不可读？从挂载选项找答案
先看一个典型场景,你在虚拟机里执行：
chmod 755 /data/app/config.yml ls -l /data/app/config.yml
结果ls -l显示-rwxr-xr-x，但普通用户cat仍然提示Permission denied，这时不要继续重复chmod 777,而要看挂载：
findmnt -T /data/app/config.yml mount | grep /data
常见挂载问题有：
/dev/sdb1 on /data type vfat，vfat不存储Linux权限，chmod可能返回成功，但权限由挂载参数uid、gid、umask、fmask、dmask决定。ro只读挂载，文件系统出错后，内核可能自动重挂为只读。chmod会报Read-only file system,也可能看似成功但没有写入。nfs挂载，NFS服务端控制权限，客户端chmod是否生效取决于服务端导出选项、root_squash和NFS版本。cifs挂载，SMB/CIFS权限由服务端ACL决定，客户端挂载参数file_mode、dir_mode、noperm会覆盖本地权限判断。-
noacl挂载，即使文件有ACL,内核也可能不按ACL规则放行。
修复思路很直接：
# 只读改读写，先确认没有文件系统错误 mount -o remount,rw /data # vfat/exfat重新挂载，让所有文件映射到指定用户 mount -o remount,uid=1000,gid=1000,umask=022 /dev/sdb1 /data # NFS挂载时启用ACL，具体选项看服务端支持 mount -o remount,vers=4.2,acl server:/export /data
云服务器和本地虚拟机chmod权限差异对比：NFS与SMB更常见
云服务器和本地虚拟机看起来都是Linux，但权限问题来源不同，本地虚拟机常用ext4、xfs，chmod通常直接生效，云服务器经常挂载云盘、NAS、对象存储网关,权限模型会变复杂。
| 场景 | chmod是否直接生效 | 常见拦截点 | 优先检查 |
|---|---|---|---|
| ext4/xfs本地盘 | 是 | ACL、SELinux、父目录 | getfacl、ls -Z |
| FAT32/exFAT | 否 | 不存储POSIX权限 | findmnt、umask |
| NFS | 取决于服务端 | root_squash、导出选项 |
/etc/exports、nfsstat |
| CIFS/SMB | 通常否 | 服务端ACL、noperm |
mount.cifs选项 |
| 容器绑定挂载 | 取决于UID映射 | 用户命名空间 | id、--user |
业内专家指出，Linux权限模型是“mode + ACL + 安全模块 + 挂载策略”叠加的结果，任何一层不匹配,755都可能被无效化。
Docker挂载目录chmod权限不生效场景：容器内外UID映射
容器里最容易出现“宿主机可读，容器内不可读”，原因通常不是chmod没执行,而是容器进程的UID在宿主机上对应另一个用户。
例如宿主机文件属于uid=1000，容器内应用以uid=100运行，容器内看文件可能是755，但内核按宿主机UID检查,仍然拒绝。
排查命令：
# 宿主机查看文件属主 stat -c '%u:%g %a %n' /data/app/config.yml # 容器内查看当前用户 docker exec -it app id # 用指定用户运行容器 docker run --user 1000:1000 -v /data/app:/app myimage
如果容器使用用户命名空间，/proc/sys/user/max_user_namespaces和/etc/subuid、/etc/subgid也会影响映射，绑定挂载下，文件inode权限由宿主机内核检查，容器内chmod可能改到宿主inode,也可能因权限不足失败。
华东地区云主机chmod权限修复实操与Linux权限修复费用边界
如果云主机在华东地区，控制台能登录、SSH能连，但Web服务读不了文件,按下面顺序查：
确认当前用户和目标用户：
id sudo -u www-data cat /var/www/html/index.php
确认路径每一级目录都有执行权限：
namei -l /var/www/html/index.php
父目录没有x,子文件755也没用。
查看ACL：
getfacl -p /var/www/html/index.php
如果mask是，即使mode显示755，有效权限也可能被限制,可用：
setfacl -m m::r-x /var/www/html/index.php setfacl -b /var/www/html/index.php
查看SELinux：
getenforce ls -Z /var/www/html/index.php ausearch -m avc -ts recent
如果上下文不对,用：
restorecon -Rv /var/www/html semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.)?" restorecon -Rv /var/www/html
查看不可变属性：
lsattr /var/www/html/index.php chattr -i /var/www/html/index.php
至于Linux权限修复一般多少钱，多数云厂商的基础工单不单独收费，第三方运维按次或按小时报价，价格因地域、响应级别和服务商不同，没有统一标准，华东地区云主机通常先走免费工单和自助排查,紧急生产故障才考虑付费支持。
从命令到验证：一套可复用的排查流程
行业共识认为，遇到chmod
不生效，应先看挂载，再看安全上下文，最后看ACL和UID映射,可以按下面流程走：
- 第一步，记录现象，保存
ls -l、id、findmnt -T、getfacl输出。 - 第二步，换用户测试，用
sudo -u 目标用户 test -r 文件验证真实可读性。 - 第三步，检查挂载，确认不是
ro、vfat、nfs、cifs或noperm。 - 第四步，检查安全模块，SELinux看
avc denied，AppArmor看dmesg。 - 第五步，检查ACL和父目录。
namei -l能快速定位哪一级缺x。 - 第六步，修复后复测，不要只看
ls -l,要用目标进程实际读取。
验证命令示例：
sudo -u www-data test -r /var/www/html/index.php && echo readable namei -l /var/www/html/index.php getfacl -p /var/www/html/index.php ls -Z /var/www/html/index.php
虚拟机chmod权限不生效常见问答
chmod 777后文件还是不可读，怎么办？
777只改mode，不能绕过只读挂载、FAT/exFAT权限映射、NFS服务端ACL、SELinux拒绝或父目录缺x，先执行findmnt -T 文件路径、getfacl 文件路径、ls -Z 文件路径，再决定是改挂载参数、恢复安全上下文,还是调整ACL。
chmod权限修改后需要重启虚拟机吗？
通常不需要。chmod立即修改inode mode，内核在下一次权限检查时就会使用新值，NFS属性缓存可能导致短时间延迟，可用stat强制刷新或重新挂载，SELinux上下文修复用restorecon立即生效，只有文件系统进入只读状态时，才需要先排查dmesg，再mount -o remount,rw。
为什么宿主机chmod生效，容器内还是拒绝访问？
因为容器内进程的UID/GID在宿主机上映射成了另一个身份，绑定挂载不会把权限“翻译”成容器用户，内核只认宿主UID和inode mode，让容器以文件属主UID运行，例如docker run --user 1000:1000，或把文件chown为容器实际UID,才能让755真正放行读取。