1. 问题现象与核心场景剖析

最近在给一台CentOS 7的虚拟机传文件时，系统弹出了一个让人有点头疼的报错：“error when getting information”。这个错误本身描述很模糊，它只是告诉你“获取信息时出错”，但具体是获取什么信息、为什么出错，一概没说。这就像你去办事，窗口工作人员只跟你说“办不了”，却不告诉你缺了哪份材料一样，让人无从下手。根据我的经验，这个报错在多种文件操作场景下都可能出现，比如使用scp命令从本机复制到虚拟机、在VMware或VirtualBox的共享文件夹里操作、甚至是使用cp或mv命令在虚拟机内部移动文件时。问题的根源，往往不在于你要复制的那个文件本身，而在于文件所处的路径环境——包括权限、所有权、SELinux上下文，甚至是文件系统本身的健康状况。

为什么这个问题在CentOS 7虚拟机上特别常见？首先，CentOS 7作为一款曾经非常稳定且广泛使用的企业级Linux发行版，其默认的安全配置（尤其是SELinux）相对严格。很多从Windows或更宽松Linux环境迁移过来的用户，很容易在这里“踩坑”。其次，虚拟机环境增加了一层复杂性。文件可能来自宿主机的共享目录，这个目录的挂载方式、权限映射（如virtiofs或vboxsf的挂载选项）都会直接影响虚拟机内的访问行为。最后，这个报错是一个“伞式错误”，它掩盖了底层真正的病因，可能是权限不足、路径不存在、SELinux阻止，或者是磁盘错误。

2. 根因深度排查：从表象到本质的四层诊断

遇到“error when getting information”，盲目尝试解决是低效的。我们需要像医生一样，进行系统性的诊断。下面这个排查流程，是我经过多次实战总结出来的，能帮你快速定位到问题所在。

2.1 第一层：基础权限与所有权检查

这是最常见也是最容易检查的一层。Linux的一切皆文件，而每个文件都有严格的所有者（owner）、所属组（group）和其他人（others）的读（r）、写（w）、执行（x）权限。

诊断操作：使用ls -la命令查看目标文件或目录的详细信息。

ls -la /path/to/your/file_or_directory

关键解读：

1. 权限位（首列）：例如-rw-r--r--。你需要关注当前操作的用户是否拥有相应的权限。如果你是用普通用户身份去复制一个属于root且权限为-rw-------（仅root可读可写）的文件，必然会失败。
2. 所有者和所属组（第3、4列）：确认文件是否属于你，或者你所在的组是否有权限。
3. 父目录权限：记住，对文件进行操作，你必须拥有该文件所在目录的执行（x）权限。这是新手常忽略的一点。即使文件权限是777，如果它的父目录不允许你进入（即没有x权限），你同样会“error when getting information”。

解决方案：

• 修正权限：sudo chmod命令。例如，给文件所有者添加读权限：sudo chmod u+r filename。
• 更改所有者：sudo chown命令。例如，将文件所有者改为当前用户：sudo chown $USER filename。
• 修正目录权限：确保你能cd到目标目录。如果需要，使用sudo chmod u+x directoryname为目录添加执行权限。

注意：在生产环境中，谨慎使用chmod 777或chown -R递归修改整个目录树，这会带来严重的安全风险。应该遵循最小权限原则，只授予必要的权限。

2.2 第二层：SELinux上下文拦截

这是CentOS/RHEL系系统特有的“防火墙”，也是导致许多灵异问题的罪魁祸首。SELinux（安全增强式Linux）不仅控制谁可以访问文件（DAC，自主访问控制），还控制进程可以访问哪些文件（MAC，强制访问控制）。即使你的用户权限（rwx）完全正确，如果SELinux策略不允许当前进程（比如cp命令背后的进程）访问带有特定“标签”（上下文）的文件，操作也会被拒绝。

诊断操作：

1. 检查SELinux状态：getenforce。如果返回Enforcing，说明它正在严格运行。
2. 查看文件或目录的SELinux上下文：ls -Z /path/to/your/file_or_directory。 你会看到类似这样的输出：unconfined_u:object_r:user_home_t:s0。其中user_home_t就是文件类型标签。
3. 查看进程的SELinux上下文：ps -eZ | grep [process]，或者直接看你的shell上下文：id -Z。

常见冲突场景：

• 你从/tmp（上下文通常是tmp_t）复制一个文件到你的家目录（user_home_t），这通常是允许的。
• 但是，如果你尝试将一个文件从虚拟机共享文件夹（例如，VMware挂载的目录，其上下文可能是vmblock_t）复制到Web服务器的根目录（httpd_sys_content_t），SELinux就很可能阻止这个操作，因为cp进程（运行在unconfined_t或staff_t域）不被策略允许直接在这两种差异巨大的上下文之间搬运数据。

解决方案：

1. 临时方案（调试用）：将SELinux设置为宽容模式：sudo setenforce 0。然后重试复制操作。如果成功了，那基本可以断定是SELinux问题。切记，调试完要改回来：sudo setenforce 1。
2. 永久方案（不推荐）：禁用SELinux。编辑/etc/selinux/config，将SELINUX=enforcing改为SELINUX=disabled，然后重启。这会降低系统安全性，仅作为最后手段或在明确不需要SELinux的环境中使用。
3. 正确方案：修复文件上下文。
   • 恢复默认上下文：使用restorecon命令。例如，对一个目录及其下所有文件恢复默认标签：sudo restorecon -Rv /path/to/directory。这个命令会根据系统策略数据库（/etc/selinux/targeted/contexts/files/）中的规则，给文件打上正确的标签。
   • 手动设置上下文：使用chcon命令。例如，将一个文件的上下文设置为和家目录一样：sudo chcon -R -u unconfined_u -r object_r -t user_home_t /path/to/file。但更推荐先使用restorecon。

2.3 第三层：文件系统与挂载点问题

这一层问题相对隐蔽，但一旦发生，影响范围可能更广。

诊断操作：

1. 检查挂载点是否存在：df -h查看所有挂载点，确认你操作的路径是否在一个已挂载的文件系统上。
2. 检查挂载选项：特别是对于共享文件夹。使用mount命令或cat /proc/mounts查看挂载详情。
   • 对于VMware HGFS共享：查找是否有vmhgfs类型的挂载，并检查其选项，如uid,gid,dmask,fmask。这些选项决定了挂载点内文件在虚拟机中呈现的权限。例如，如果挂载时指定了fmask=133，那么文件的权限位就会是644（即所有者可读写，其他人只读），这可能会影响你的复制操作。
   • 对于VirtualBox共享：查找vboxsf类型的挂载。
3. 检查文件系统错误：如果怀疑磁盘有问题，可以使用fsck命令（务必在卸载或只读模式下进行，否则可能导致数据损坏）。对于正在运行的系统，可以查看系统日志dmesg | tail或/var/log/messages中是否有I/O错误记录。

解决方案：

• 重新挂载共享文件夹：以正确的权限选项重新挂载。例如，在VMware中，确保VMware Tools已正确安装，并在/etc/fstab或挂载命令中指定合适的uid,gid,umask等参数。
• 修复文件系统：如果确认是文件系统错误，需要进入救援模式或使用Live CD/USB启动，然后对目标分区执行fsck。

2.4 第四层：路径与符号链接陷阱

路径问题看似简单，但在脚本或复杂目录结构中很容易出错。

诊断操作：

1. 检查路径是否存在：ls -ld /the/full/path。注意-d参数是查看目录本身，而不是其内容。
2. 检查是否为符号链接及其目标：ls -l /path/to/link会显示-> target。你需要确保符号链接本身和其指向的目标都有正确的权限。
3. 检查路径中是否包含空格或特殊字符：在命令行中，如果路径包含空格，必须用引号括起来，如cp “source file.txt” destination/。否则，命令会将其解析为多个参数。

解决方案：

• 使用绝对路径而非相对路径，减少歧义。
• 对包含特殊字符的路径，始终使用引号。
• 检查并修复断裂的符号链接（指向不存在的目标）。

3. 分场景实战解决方案与操作实录

理论分析完毕，我们进入实战环节。针对不同的文件来源和复制方式，解决方案的侧重点不同。

3.1 场景一：使用SCP/SFTP从宿主机复制到虚拟机

这是跨网络的文件传输方式，通常涉及SSH服务。

问题复现与诊断：

scp ./local_file.txt user@centos7_vm_ip:/home/user/

报错：scp: /home/user/local_file.txt: error when getting information

解决步骤：

1. 确认目标路径权限：首先SSH登录到虚拟机，检查/home/user/目录的权限和所有者。确保你的用户对该目录有写（w）和执行（x）权限。
2. 检查磁盘空间：df -h /home，确保目标分区有足够空间。
3. 检查SELinux对SSH的影响：SELinux有一个布尔值控制SSH服务是否可以将文件写入用户家目录。检查并确保其开启：

   getsebool -a | grep ssh # 关注 ssh_keysign 和 ssh_sysadm_login，但更重要的是，确保家目录上下文正确。 # 如果家目录上下文异常，SCP写入会失败。 sudo restorecon -Rv /home/user

4. 检查SSH服务配置（较少见）：确保/etc/ssh/sshd_config中没有限制性过强的配置，如ChrootDirectory或ForceCommand，这些可能会限制SCP/SFTP的功能。

3.2 场景二：通过VMware/VirtualBox共享文件夹复制文件

这是最易出问题的场景，因为涉及虚拟化层的文件系统驱动和权限映射。

以VMware为例的深度排查：

1. 确认VMware Tools已安装且运行：vmware-toolbox-cmd -v或ps aux | grep vmtoolsd。没有正确安装Tools，共享文件夹功能无法使用。
2. 检查共享文件夹是否挂载：vmware-hgfsclient命令可以列出宿主机共享的目录名。mount | grep vmhgfs查看是否已挂载。通常挂载在/mnt/hgfs。
3. 手动挂载（如果未自动挂载）：

   sudo mkdir -p /mnt/hgfs sudo /usr/bin/vmhgfs-fuse .host:/ /mnt/hgfs -o subtype=vmhgfs-fuse,allow_other,uid=1000,gid=1000

   这里uid和gid要换成你虚拟机中用户的ID（可通过id -u和id -g查看）。allow_other选项允许其他用户访问。
4. 检查挂载点权限：挂载后，检查/mnt/hgfs及其下的共享文件夹权限。由于FUSE文件系统的特性，即使宿主机文件是777，在虚拟机里也可能因为挂载选项而显示为不同的权限。这是“error when getting information”的高发区。你需要确保你的用户对/mnt/hgfs/your_shared_folder有访问权限。
5. SELinux对FUSE的管制：SELinux默认策略可能阻止用户空间的FUSE文件系统（如vmhgfs-fuse）访问某些类型的文件。如果以上步骤都正确，但复制仍报错，尝试在复制时查看SELinux审计日志：

   sudo tail -f /var/log/audit/audit.log | grep avc

   如果看到关于fuse或vmhgfs的 AVC denied 信息，你需要调整SELinux策略。一个临时的解决方法是添加相应的SELinux模块规则，或者（仅限测试环境）设置一个布尔值：

   sudo setsebool -P virt_use_fusefs on

VirtualBox共享文件夹的特别注意事项：VirtualBox的共享文件夹需要安装“增强功能”（Guest Additions），并手动将用户添加到vboxsf组，才能获得写权限。

# 安装增强功能后，挂载共享文件夹 sudo mount -t vboxsf shared_folder_name /mnt/share # 将当前用户添加到vboxsf组 sudo usermod -aG vboxsf $USER # **重要：** 重新登录后用户组更改才会生效。

同样，也需要检查SELinux对vboxsf文件系统的限制。

3.3 场景三：在虚拟机内部使用CP/MV命令复制文件

这个场景排除了网络和虚拟化层，问题更集中在Linux系统本身。

操作实录与排查：假设你在虚拟机内执行cp /var/log/messages ~/backup/报错。

1. 逐级检查路径：
   • 源文件：ls -laZ /var/log/messages。确保可读。
   • 目标目录：ls -laZd ~/backup/。确保存在且你有写和执行权限。如果~/backup不存在，cp命令会尝试将messages文件重命名为backup，这显然会失败。你需要的是cp /var/log/messages ~/backup/（backup是目录）或cp /var/log/messages ~/backup（backup是不存在的文件，cp会创建它）。这里一个斜杠的差别，语义完全不同。
2. 使用strace进行终极诊断：如果以上都正常，问题依然存在，可以使用strace工具跟踪系统调用，看cp命令到底在哪一步卡住了。

   strace cp /var/log/messages ~/backup/ 2>&1 | tail -20

   在输出中搜索error、-1（表示系统调用失败）以及紧随其后的EACCES（权限拒绝）、ENOENT（文件不存在）、EIO（I/O错误）等错误码。这能最精确地定位问题。

4. 高频问题排查清单与独家避坑指南

根据多年运维经验，我整理了下面这个速查表。遇到“error when getting information”，按照下表从上到下排查，99%的问题都能解决。

独家避坑心得：

1. “先松后紧”调试法：当问题复杂时，我习惯先创建一个最宽松的测试环境：在目标位置创建一个权限为777的临时目录，然后尝试复制。如果成功，说明问题在路径权限上；如果失败，则问题很可能在SELinux或文件系统层面。这样可以快速缩小排查范围。
2. 善用—preserve参数：使用cp时，-a（归档模式，相当于-dR —preserve=all）或—preserve=context参数可以在复制时保留SELinux上下文，这在一些严格的环境中非常有用，可以避免复制后文件上下文丢失导致的服务无法访问。
3. 共享文件夹的“uid/gid”映射是核心：在虚拟机设置共享文件夹时，宿主机上的文件只有一个“所有人”的概念（比如你的Windows用户名）。映射到Linux虚拟机时，你需要通过挂载选项（uid，gid）明确指定它对应虚拟机里的哪个用户和组ID。务必使用数字ID（id -u），而不是用户名，因为用户名可能在宿主机和虚拟机中不存在或不一致。
4. 审计日志是你的朋友：/var/log/audit/audit.log是SELinux的“黑匣子”。任何拒绝操作都会在这里留下详细的AVC记录。使用sealert -a /var/log/audit/audit.log或ausearch -m avc -ts recent命令可以获取更易读的分析建议，它会直接告诉你可以运行哪条setsebool或semanage命令来解决问题。
5. 考虑使用Rsync替代SCP：对于大量文件或需要保留属性的复制，rsync比scp更强大、更可靠，并且有更详细的错误输出和进度提示。命令类似：rsync -avz ./local_dir/ user@vm_ip:/remote/path/。它的-v（详细）和—progress选项能让你更清楚地看到复制过程卡在哪里。