ls 不显示文件，多数情况下不是虚拟机出了问题，而是命令执行的位置、所用权限和挂载状态这三件事出了岔子。 按“确认当前目录确认权限确认挂载”的顺序排查，绝大多数情况五分钟内就能定位问题。
先分清“看不见”和“不存在”：三个命令定位问题
很多人遇到 ls 没输出，第一反应是“文件被删了”或者“系统坏了”，这种判断太早。命令行世界里，“看不见”和“不存在”是两码事。 三个命令就能帮你分清。
- 先敲 pwd，确认自己站在哪个目录里，虚拟机里多块磁盘、多个挂载点很常见，你以为在
/data，实际可能还在/root。 - 再敲 ls -la，看隐藏文件，文件名以 开头的文件，默认 ls 不会显示。
ls -a和ls -la的区别只在于后者多显示权限、属主、大小和时间，排查时建议直接用 ls -la。 - 最后用 stat /目标路径，确认这个路径到底存不存在、是不是符号链接，如果输出
No such file or directory，那就不是“不显示”，而是“本来就没有”。
一个容易忽略的细节：ls 命令本身有自己的退出码。 如果目录存在但内容为空，ls 退出码是 0，屏幕上没有任何输出，如果目录不存在，退出码是 2，但部分终端配置下错误信息可能被吞掉，看起来就像“ls 没反应”，所以排查时养成习惯，每条命令后面跟上 echo $?，一眼就能看出命令是否正常执行完毕。
权限问题：普通用户 ls 不出 root 目录内容
在 centos7 ls 看不到文件，很多时候是权限挡在中间。 这条经验同样适用于 Ubuntu、Debian、openEuler 等其他发行版。
虚拟机里常用的登录账号是普通用户,而网站数据、数据库文件、备份目录通常放在 /root、/home 或其他受限目录下，普通用户执行 ls /root，系统会返回 Permission denied，如果终端界面没刷新或者你滚动过快，这行报错很容易被忽略，看起来就像“命令没反应”。
具体检查三步：
- 用 ls -ld /目标目录 查看目录权限位，重点看第三位（其他用户权限），权限码是
700或750时，普通用户确实进不去。 - 用 sudo ls -la /root 来验证，sudo 之后能看到文件，说明权限配置就是根因。
- 用 namei -l /目标路径 查看完整路径上每一层目录的权限，能快速定位是哪一层目录卡住了你。
这里有一个高频场景：linux sudo ls 没反应，先确认 sudo 本身是否可用。 如果当前用户不在 sudo 组里，命令会直接报错而不是列出文件，用 groups 当前用户名 检查一下成员身份，虚拟机上这个问题尤其常见，因为初始化时为了方便干脆禁用了 root 密码，又没给普通用户配置 sudo 权限。
虚拟机挂载硬盘 ls 看不到文件？先从挂载状态查起
这是一个让很多人抓狂的经典场景：挂载硬盘后 ls 看不到文件，磁盘命令 df 里也没有那块盘的影子。 你的数据其实还安安静静地躺在磁盘里，只是系统压根没把它接进目录树。
出现这种情况的第一嫌疑是挂载步骤没走完,虚拟机控制台上“添加硬盘”只是把一块裸设备交给了系统，你还得自己完成分区、格式化、挂载三步，只做完前两步就去看 ls，自然是空的。
排查时按这个顺序执行：
- 输入 lsblk，看系统认没认出这块盘。
NAME列出现sdb、vdb、nvme0n1这类名字，说明设备层正常。 - 输入 df -hT，看它有没有挂载到某个目录，如果列表里完全没有这个设备，直接跳去下一步。
- 输入 blkid /dev/sdb1，拿到磁盘的 UUID 和文件系统类型，没有任何输出说明分区或格式化有问题。
- 编辑 /etc/fstab，加入一行类似
/dev/sdb1 /data ext4 defaults 0 0的配置，然后执行 mount -a 验证。
行业共识认为,fstab 里最稳的写法是直接用 UUID，而不是设备名 /dev/sdb1，设备名在虚拟机重启后可能变化（比如从 sdb 变成 sdc），UUID 却不会变，克隆虚拟机这个场景下，UUID 冲突问题尤其明显：从模板克隆出来的两台机器，磁盘 UUID 完全相同，第二台启动时系统会拒绝挂载，ls 目录自然空空如也。
业内专家指出,大多数虚拟化平台（如 VMware、VirtualBox、Proxmox VE）在克隆后允许你重新生成磁盘 UUID，具体操作在图形控制台的“编辑虚拟机设置”里通常能找到入口。
如果是 NFS 挂载，情况又多一层：服务端有文件，客户端挂载成功后 ls 却看不到，先确认网络通不通，再用 showmount -e 服务端IP 看导出列表，最后检查挂载点目录本身是不是被别的进程占用，挂载点是个非空目录的时候，NFS 挂载会把原有内容暂时盖住，ls 看到的是远端数据而不是本地数据，最容易引起误解。
目录文件都在，ls 输出被 SELinux 挡住了
SELinux 是另一个能让 ls “看似失灵”的元凶，尤其在没有关闭 SELinux 的 CentOS 和 RHEL 虚拟机上。SELinux 控制的是进程对文件的访问权限，不是用户的访问权限。 你手动敲 ls 能看到文件，但 Apache、Nginx、MySQL 这类后台服务读不到目录，日志里全是 Permission denied，换句话说：你用 SSH 登录后 ls 显示的可能是正常内容，服务却在报错。
先执行 getenforce 看状态，输出 Enforcing 表示正在强制模式，Permissive 是只记录不拦截，Disabled 是完全关闭，如果是 Enforcing，再用 ls -Z 目标目录 看文件的 SELinux 上下文。
对比 system_u:object_r:httpd_sys_content_t 和 system_u:object_r:default_t 这两套标签，你就明白问题所在：文件挂到了 /www 目录，标签却是 default_t，Web 服务根本不允许读取，修正方式是用 restorecon -Rv /www 恢复默认标签，或者用 chcon -t httpd_sys_content_t /www/文件名 手动指定类型。
避免这个问题最干净的办法是：目录一旦决定给服务用，/data、/www、/var/lib/mysql，先按服务的标准路径来规划，别图省事把数据随便丢在 /mnt 下，然后一边调 SELinux 一边猜标签，既浪费时间又容易引入新问题。
文件系统报错：ls 有输出但内容残缺
有一种更隐蔽的情况：ls 能执行，输出也有，但文件数量明显不对，而且伴随输入输出错误提示，这往往指向文件系统损坏，而不是权限或挂载问题。
虚拟机的数据盘如果经历过异常断电,或者宿主机强制重置（比如机房断电后自动重启），ext4 和 xfs 文件系统都可能留下不一致的状态，这时 dmesg 尾部通常会有明显的报错，EXT4-fs error (device sdb1) 或 Buffer I/O error on device。
先跑 dmesg | tail -n 50 确认硬件的健康状态，再用 df -hT 检查文件系统是否已经变成只读（ro 标记），只读状态下，ls 能看到部分文件，但新增、删除、改名都会失败，而大多数用户不会第一时间发现这些操作“悄悄失败了”。
修复文件系统必须记住一个原则：先备份，再操作。 云平台快照或虚拟化平台的快照功能，把整个磁盘状态保存一份之后再进行修复，具体修复流程是先卸载对应分区（umount /data），再执行 fsck -y /dev/sdb1，让工具自动修复检查到的错误，如果是系统根分区，无法卸载，就得进救援模式或者用同一平台的临时虚拟机挂载这块盘再修复。
据统计,这类问题在频繁强制重启的虚拟机上出现概率明显更高，养成“重启前先执行 shutdown -r”的习惯，能避开绝大多数的文件系统不一致问题。
按顺序排查：一套命令快速定位所有原因
把上面所有排查思路整理成一套命令序列,按照执行顺序逐条跑，每一行都有明确的判断含义：
- pwd 确认当前工作目录，这里有个高频错误：从侧边栏直接跳目录时，实际目录并不是你想的那个。
- ls -la | head -n 30 看隐藏文件，同时避免文件太多刷屏。
- df -hT /目标目录 看这个目录落在哪个文件系统上，有没有挂载，剩余空间多少。
- lsblk 看系统是否识别整块磁盘和分区。
- sudo -i 切换到 root，排除普通用户权限不足的可能，如果是配置好了免密 sudo 的环境，这一步不影响操作速度。
- getenforce 一步确认 SELinux 状态，不用猜。
- dmesg | tail -n 30 看有没有磁盘错误或者文件系统报错，这是最后一道关卡。
这套命令跑到第五步通常就能解决问题,跑到第七步还没发现异常，问题就从“ls 不显示文件”变成了“文件的产生方式是否正确”比如程序是否真的在写这个目录，crontab 是否执行成功，这些就是日志层面的事了。
关于虚拟机 ls 命令不显示文件怎么办的 Q&A
问：为什么在 / 目录下 ls 有内容，进了 /data 目录后 ls 什么都不显示？
答：/data 目录可能是在系统安装前创建的空目录，你准备的数据盘还没有挂载到它上面，执行 df -hT /data 看看它属于根文件系统还是独立分区的挂载点，如果显示成 /dev/sda1 或根文件系统，说明数据盘并没有挂载到这里，你需要把数据盘的 UUID 写入 /etc/fstab，然后执行 mount -a，再回到 /data 执行 ls 验证文件是否出现。
问：fstab 写错了导致虚拟机启动后卡在维护模式，ls 看不到原来的文件，如何恢复？
答：在维护模式输入 root 密码登录，先执行 mount -o remount,rw / 让根文件系统可写，然后查看 /etc/fstab 中最近修改的行，最常见的问题是 UUID 复制错误或文件系统类型写错，用 blkid 查看真实 UUID，用 vim /etc/fstab 修正后执行 mount -a 验证，确认无误后重启系统，如果无法进入维护模式，用虚拟机安装镜像的救援模式，或者使用虚拟化平台自带的恢复工具同样可以编辑根目录下的 fstab 文件。
问：挂载的磁盘 ls 显示目录为空，但宿主机上能看到数据，是不是格式化了错误的设备？
答：检查 mount 命令输出中挂载点对应的设备路径，再对比 lsblk 中每个设备的容量和分区表，重点确认挂载的确实是包含数据的分区，而不是新添加的空白硬盘，两块磁盘容量相同时特别容易搞混，稳妥的做法是执行 umount /data 之后，用 mkdir -p /临时目录 && mount /dev/正确的设备 /临时目录 做一次验证，将数据盘挂载到临时目录，用 ls /临时目录 查看原有文件是否可见，确认无误后，再把它正常挂载到 /data。