Windows 上传文件到虚拟机：共享文件夹、SFTP、Samba、拖拽

把 Windows 上的文件塞进虚拟机，这件事听起来像是"复制粘贴"级别的小操作，但真正在虚拟机里跑过开发环境、部署过测试服务的人都知道，它能在深夜两点钟把人卡住。我做本地开发环境有几年了，宿主机常年是 Windows，虚拟机里装着 Linux，每天都要在两边倒腾代码、压缩包、数据库脚本、日志文件。windows 上传文件到虚拟机这事，我前后用过至少五六种方式，踩过的坑从"共享文件夹挂载后是空的"到"SFTP 传上去的文件属主变成 root 导致 IDE 写不进去"，基本集齐了。这篇就把我实际在用的四种方法完整拆一遍：共享文件夹、SFTP/SCP 远程传输、Samba 网络驱动器映射、拖拽与剪贴板直传，再补一套应急方案和一份排查清单。不管你是刚装完虚拟机的初学者，还是已经能熟练敲命令但总被权限和网络模式绕晕的开发者，这四种方法里总能挑出一个适合你当前场景的组合。

1. 四种传输方案的选型逻辑与适用场景对比

1.1 为什么"传文件"值得单独拿出来讲

我先说清楚这件事的复杂度来源。Windows 和 Linux 虚拟机之间，虽然物理上跑在同一台机器里——你的硬盘上就躺着那个几十 GB 的 vmdk 文件——但它们在操作系统层面是两个完全隔离的世界。虚拟机有自己的网卡、自己的文件系统、自己的用户体系和权限模型。你在 Windows 资源管理器里看得见的是 C 盘、D 盘，看不见虚拟机里 ext4 分区里的任何一个目录。这种隔离是虚拟化技术的核心价值，也是传输文件必须走一条"通道"的根本原因。

通道怎么选，取决于三个变量：文件大小和数量、传输频率、以及你对"传完之后权限对不对"的要求。一次性传一个 4GB 的 ISO 镜像，和每天改完代码要同步十几个小文件，最优解完全不一样。前者你要考虑的是稳定性和断点续传，后者你要考虑的是操作成本和自动化程度。很多人上来就问"哪种方法最好"，这个问题本身没有答案，因为答案取决于场景。我下面会把四种方法各自的适用边界讲清楚，你自己对号入座。

另外还有一个容易被忽略的变量：虚拟机的网络模式。VMware 有桥接、NAT、仅主机三种模式，Hyper-V 也有自己的虚拟交换机逻辑。网络模式直接决定了宿主机能不能"看见"虚拟机，也决定了很多传输方案是不是走得通。我在第 2 到第 5 节里会针对每种方法说明它依赖哪种网络模式，这个前置知识不搞清楚，后面全是无用功。

1.2 四种方法的横向对比与选型建议

先上一张对比表，让你对全局有个印象，后面再逐个展开细节。

选型上我自己的习惯是这样：日常写代码的目录用共享文件夹，因为改完保存就是实时的，不需要手动"上传"这个动作；要部署到另一台真正的服务器、或者虚拟机不在本机的时候，用 SFTP；需要把虚拟机的某个目录当成 Windows 盘符长期挂着用的，用 Samba；临时传一个配置文件、一段 SQL 语句，直接用拖拽或者剪贴板。

注意：不要把共享文件夹当成"生产级"的数据通道。它的本质是 VMware 提供的一层文件系统桥接，在网络模式切换、快照回滚、工具版本升级之后经常需要重新挂载。关键数据永远在宿主机上留一份备份。

2. 共享文件夹：装完工具后的第一选择

2.1 共享文件夹的工作原理与前置条件

共享文件夹的实现机制，是宿主机和虚拟机之间通过 VMware 提供的虚拟设备建立一条文件系统级别的直通通道。宿主机上的某个目录被"暴露"出来，虚拟机内核里加载一个叫 vmhgfs 的文件系统驱动，把它挂载到 Linux 的某个目录下。挂载完成之后，你在虚拟机里访问 /mnt/hgfs/xxx，实际上读写的就是宿主机硬盘上的那个目录，双方看到的是同一份数据，没有复制过程，也没有额外的传输协议开销。

这个机制决定了它的两个优点：第一，速度快，因为不经过网络协议栈，大文件拷贝能跑到接近磁盘的顺序读写带宽；第二，双向实时，宿主机改一个字符，虚拟机里立刻就能看到，反过来也一样。这也是我把它放在第一位的原因——对于开发场景，这种"零操作成本"的体验没有任何替代品。

但它有三个硬性前置条件，缺一不可。第一，虚拟机必须安装 open-vm-tools 或者官方的 VMware Tools，而且必须是带桌面组件的完整版；第二，虚拟机的设置里必须显式启用共享文件夹功能并添加具体目录，这个开关默认是关的；第三，虚拟机需要能正常挂载 fuse 文件系统，因为现代版本的 vmhgfs 是用 FUSE 实现的。

在 Ubuntu/Debian 系上，安装命令是这两条：

sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop

CentOS/Rocky/统信 UOS 这类系统用：

sudo yum install -y open-vm-tools open-vm-tools-desktop # 或者在新版本上 sudo dnf install -y open-vm-tools open-vm-tools-desktop

装完重启一次虚拟机，让内核模块正常加载。这里有个细节：很多人装完 open-vm-tools 之后发现 /mnt/hgfs 是空目录，以为是配置错了，其实是共享文件夹这个"开关"本身还没打开，跟你装没装工具是两回事。工具负责提供驱动，开关负责提供内容，两者得同时具备。

2.2 从零配置共享文件夹的完整步骤

第一步，先在宿主机上准备好要共享的目录。我的习惯是在非系统盘建一个固定路径，比如D:\vm-share，不要放在桌面或者用户目录里，因为那些路径经常带中文和空格，虽然理论上支持，但在挂载脚本里处理起来很烦。目录建好之后，把要传的文件放进去，或者留空都行。

第二步，关掉虚拟机（挂起状态有时读不到新配置，建议完全关机），在 VMware Workstation 里右键虚拟机 → 设置 → 选项选项卡 → 共享文件夹。默认选的是"已禁用"，改成"总是启用"。然后点下面的"添加"按钮，走一遍向导：主机路径选D:\vm-share，名称填一个纯英文的名字比如share，这个名称后面挂载的时候要用到，别用中文。属性里勾选"启用此共享"，读写权限按需要选。

第三步，启动虚拟机，确认共享名称已经被识别。执行：

vmware-hgfsclient

如果输出里有你刚才设置的名称，说明宿主机侧的配置已经生效。如果没有输出，说明工具没装好、或者共享开关没打开、或者虚拟机需要重启，三个方向依次排查。

第四步，挂载到本地目录。这里我强烈建议手工挂载一次确认成功，再写进 fstab，因为直接写 fstab 出错会导致系统起不来，排查成本很高。手工挂载命令：

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

这条命令里几个参数都是有意义的，不是抄来的模板。allow_other让非 root 用户也能访问，不加的话只有 root 能进去；uid和gid指定挂载后文件的属主，1000 通常是你自己的普通用户，不加的话所有文件都会显示为 root 所有，你在 IntelliJ IDEA 或者 VS Code 里想改文件就会提示没权限；umask=022控制新建文件的默认权限，算是一个安全的默认值。

如果执行时报fuse: failed to open /dev/fuse或者类似的错误，检查一下 fuse 是不是装了：

sudo apt install -y fuse

还有一种情况是提示allow_other不被允许。这是 fuse 的安全默认值在起作用，需要打开/etc/fuse.conf，把里面user_allow_other这一行的注释去掉，然后重新挂载。

2.3 开机自动挂载与权限踩坑记录

手工挂载成功之后，如果不想每次重启都敲一遍命令，可以写进/etc/fstab：

.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,uid=1000,gid=1000,umask=022,defaults 0 0

注意设备名写的是.host:/而不是某个具体共享名，这样挂载之后/mnt/hgfs/下面会直接出现你配置的所有共享目录。写完先别急着重启，用sudo mount -a测试一下，没有报错才算通过。这一步能帮你避开"改完 fstab 系统进不去"的经典事故。

我在权限上踩过的坑主要集中在这几个点。一是共享文件夹里的文件，在 Linux 侧执行chmod和chown是无效的，因为底层实际承载权限的是宿主机 NTFS 文件系统，Linux 只能通过挂载参数统一指定，没法对单个文件做区分。这意味着如果你要在虚拟机里跑一个要求严格权限位的服务，比如 SSH 私钥必须是 600，共享目录里的文件是做不到的，这种情况只能把私钥复制到虚拟机本地磁盘再改权限。二是符号链接常常失效，Linux 侧创建的软链接在宿主机上看到的是一个无法识别的文件，因为 Windows 的链接机制跟 Linux 完全不是一回事。三是文件名大小写，如果代码里有README.md和readme.md两个文件，在共享目录里会互相覆盖，NTFS 默认不区分大小写。

提示：如果你的项目里有大量小文件，比如 node_modules 这种几万个文件的目录，强烈建议不要放在共享文件夹里。跨文件系统的元数据操作开销会非常明显，装依赖的速度可能只有本地磁盘的三分之一。

另外提一个实际经验：虚拟机打快照之前，最好先确认共享文件夹里的文件状态。快照回滚的是虚拟机磁盘，不会动宿主机上的共享目录，回滚之后可能出现代码版本和数据库结构对不上的情况。我自己就遇到过一次，回滚之后代码里有新表结构，但数据库是旧的，查了半天才发现是共享目录没有跟着回滚。

3. SFTP 与 SCP：最通用也最可靠的传输通道

3.1 网络模式确认与 SSH 服务准备

共享文件夹的局限在于它只对 VMware 这种本地虚拟化方案有效，一旦你的目标机器变成一台真正的远程服务器，或者虚拟机跑在别的物理机上，共享文件夹这条路就走不通了。这时候需要的是基于网络的传输方式，而 SFTP 和 SCP 是其中最通用的一类，因为它们只依赖一个东西：SSH 服务。

先说网络前提。这一步很多人卡住，原因是对虚拟机网络模式理解不到位。使用桥接模式时，虚拟机会从路由器获取一个和宿主机同网段的 IP，比如宿主机是 192.168.1.10，虚拟机可能是 192.168.1.11，两边可以直接 ping 通，Windows 直接连虚拟机的 IP 就行。使用 NAT 模式时，虚拟机会得到一个 192.168.x.x 的私有地址（默认是 VMnet8 那个网段），这个地址宿主机是能访问的，所以本地场景下 NAT 模式也没问题。

但要注意一个反直觉的点：NAT 模式下，如果你从"虚拟机访问宿主机"的方向用宿主机的局域网 IP，可能会失败，正确的做法是用 VMware 虚拟网卡 VMnet8 的网关地址。反过来，宿主机访问虚拟机的 IP 是通畅的，这也是我们做 SFTP 传输的主方向，所以一般不用额外配置。

如果你想在 NAT 模式下用一个固定的、好记的端口来连接，可以在 VMware 的"编辑 → 虚拟网络编辑器 → 更改设置 → 选中 VMnet8 → NAT 设置 → 添加"里做端口转发。配置成"主机端口 2222，虚拟机 IP 192.168.x.x，虚拟机端口 22"，之后你在 Windows 上连接127.0.0.1:2222就等价于连虚拟机的 SSH。这个配置的好处是虚拟机 IP 变了也不影响，脚本里的地址不用改。

虚拟机侧要确认 SSH 服务在跑：

sudo systemctl status ssh # 如果没装 sudo apt install -y openssh-server sudo systemctl enable --now ssh

再用ss -tlnp | grep 22确认 22 端口处于 LISTEN 状态。如果防火墙开着，Ubuntu 上用sudo ufw allow 22，CentOS 系用sudo firewall-cmd --add-service=ssh --permanent && sudo firewall-cmd --reload。这两步做完，网络层的准备工作就齐了。

3.2 WinSCP 图形化上传的配置细节

命令行不是所有人都习惯，图形化工具里 WinSCP 是我用得最顺手的一个。新建会话时，协议选 SFTP，主机名填虚拟机 IP（或者用了端口转发就填 127.0.0.1），端口填 22（或者你转发出来的 2222），用户名密码填虚拟机里的账号。点登录，第一次连接会弹一个主机密钥确认框，接受即可。

连接上之后界面是左右两栏，左边是本机，右边是远程，直接把文件从左边拖到右边就完成上传。这里有几个细节值得说。

传输大文件的时候，点开传输设置，可以开启"传输后校验"和"保留时间戳"。保留时间戳这个选项特别重要，后面单独说。另外 WinSCP 有个"同步"功能，在命令菜单里，可以把本地某个目录和远程某个目录做增量同步，只传有变化的文件。我做静态站点部署的时候用过一段时间，比整个目录覆盖上传快得多。

编码问题也值得注意。如果文件名里有中文，而虚拟机上的 locale 不是 UTF-8，你会看到一堆乱码文件名。检查虚拟机的 locale：

locale

如果LANG不是zh_CN.UTF-8或en_US.UTF-8，建议改一下/etc/locale.conf或者/etc/default/locale，然后重新登录。这个问题不解决，上传上去的中文文件后续用命令行处理会很痛苦。

3.3 命令行 scp、pscp 与"上传后时间戳变了"的解决

命令行场景下，Windows 10 1809 之后系统自带 OpenSSH 客户端，所以scp是直接可用的。基本用法：

scp .\dist.zip user@192.168.1.100:/home/user/

传整个目录要加-r：

scp -r .\webapp user@192.168.1.100:/var/www/

这里有个 Windows 特有的坑：路径里的反斜杠和盘符，在某些 Shell 环境下会被解析错。最稳妥的写法是用正斜杠加引号：

scp "C:/work/dist.zip" user@192.168.1.100:/home/user/

还有一个性能坑。较新版本的 OpenSSH（9.0 以后）把 scp 的默认传输协议从原来的 SCP 换成了 SFTP，好处是支持更多特性，坏处是在高延迟链路上速度会明显下降。如果你发现传输速度比以前慢很多，加一个-O参数强制走老的 SCP 协议试试：

scp -O "C:/work/bigfile.iso" user@192.168.1.100:/home/user/

关于"上传到 Linux 之后文件时间被改了"这个问题，热搜里也有人在问，我专门说说。默认情况下 scp 会保留源文件的修改时间，但这只在文件系统的时间精度兼容时成立。Windows 的 NTFS 时间戳精度是 100 纳秒，Linux ext4 是纳秒级但很多场景下实际只存到秒，两者转换过程中可能有细微差异。如果你对时间戳有严格要求，比如构建系统依赖 mtime 判断是否需要重新编译，建议用-p参数显式保留：

scp -p "C:/work/src.zip" user@192.168.1.100:/home/user/

更稳妥的方案是用 rsync，它有一个专门的-t参数，而且增量传输的能力是 scp 完全比不了的：

rsync -avz --progress ./data/ user@192.168.1.100:/home/user/data/

-a是归档模式，等价于-rlptgoD一串参数的组合，其中-t就是保留修改时间，-p是保留权限。Windows 上原生没有 rsync，要么在 WSL 里跑，要么装 cwRsync 这类移植版本。

如果文件已经传上去了，事后想批量修正时间戳，可以用touch -r参照另一个文件，或者用touch -d指定时间：

touch -d "2024-05-01 10:30:00" /home/user/uploaded.txt

还有一个纯手工的小技巧：用 PowerShell 在 Windows 侧读源文件的 LastWriteTime，生成一串 touch 命令，传到 Linux 执行，能把整批文件的时间戳对齐。

注意：scp 传输过程中的权限继承规则是，文件按源文件的权限位减去 umask 后落盘，但如果你的虚拟机 sshd 配置里开启了 StrictModes（默认开启），目录权限不对会导致登录失败，所以不要随便把家目录权限改成 777。

4. Samba 映射网络驱动器：把虚拟机目录变成本地盘符

4.1 Samba 服务端的安装与共享配置

前两种方法，一个是"宿主机把目录给虚拟机"，一个是"把文件推到虚拟机"，方向感不一样。Samba 提供的是另一种体验：让虚拟机上的目录出现在 Windows 资源管理器里，像访问局域网共享文件夹一样。这对于需要频繁在 Windows 图形化工具里直接打开虚拟机文件的场景非常方便，比如用 Windows 上的编辑器直接编辑虚拟机里的配置文件。

先在虚拟机上装 Samba：

sudo apt update sudo apt install -y samba

备份原配置，然后编辑/etc/samba/smb.conf，在文件末尾追加一个共享段：

[share] comment = VM Shared Folder path = /home/user/share browseable = yes writable = yes valid users = user create mask = 0644 directory mask = 0755 force user = user

几个参数解释一下。path是要共享的目录，提前建好并确保存在；valid users限定哪些账号能访问，不写的话理论上谁都能连，不安全；create mask和directory mask决定新文件和新目录的权限位，这个如果不配，Windows 那边创建的文件可能是 600 或者更奇怪的权限，导致 Linux 侧的服务读不到；force user让所有操作都以指定用户身份执行，可以避免权限混乱，但也意味着失去了用户级别的隔离，按需使用。

配置写完之后，给 Samba 账号设置一个独立密码：

sudo smbpasswd -a user

这个密码和 Linux 系统的登录密码是分开的，别搞混。然后重启服务：

sudo systemctl restart smbd sudo systemctl enable smbd

如果系统上有 nmbd 服务也一起重启一下，它负责 NetBIOS 名称解析，虽然在纯 IP 访问的场景下不是必需的。

防火墙要放行：

sudo ufw allow samba # 或者手动 sudo ufw allow 137,138/udp sudo ufw allow 139,445/tcp

4.2 Windows 端映射与常见连接问题

虚拟机侧弄好之后，回到 Windows。最简单的做法是打开文件资源管理器，在地址栏直接输入\\192.168.1.100\share，回车，弹出的凭据框里填 Samba 用户名和刚才设置的密码。能看到目录就说明通了。

想长期使用的话，右键"此电脑" → 映射网络驱动器，选一个没用过的盘符比如 Z，路径填同样的内容，勾选"登录时重新连接"。之后每次开机 Z 盘就自动挂上了，效果和本地硬盘几乎一样，各种 Windows 软件都能直接读写。

命令行方式更干净，也适合写进脚本：

net use Z: \\192.168.1.100\share /user:user 你的密码 /persistent:yes

不想保留凭据的话，用完记得断开：

net use Z: /delete

这条路我遇到的典型问题有两个。第一个是协议版本问题。新版 Windows 10 和 Windows 11 默认禁用了 SMBv1 协议，因为它有已知的安全风险。如果你的 Samba 版本比较老，只支持 SMBv1，就会连接失败。解决办法是把 Samba 升级到较新版本，然后在配置文件里显式声明最小协议：

server min protocol = SMB2 client min protocol = SMB2

第二个是连接超时或者提示找不到网络路径，本质上还是网络不通。先用ping确认基本连通性，再用testparm检查 Samba 配置语法有没有问题，sudo testparm会输出解析结果和警告，配置写错的时候一眼就能看出来。还可以在虚拟机本地用smbclient -L localhost -U user测试服务本身是否正常，这样能把"服务问题"和"网络问题"分开定位。

提示：Samba 传输大量小文件时性能一般，因为 SMB 协议的往返开销比较大。如果只是要在虚拟机里跑服务，不建议把整个代码仓库挂成网络盘，索引速度会明显变慢。

5. 拖拽、剪贴板与 HTTP 临时通道

5.1 拖拽直传的依赖条件与失效原因

拖拽文件到虚拟机窗口里，是所有人的第一直觉。这个功能由 VMware Tools 的桌面增强组件提供，前提是你装了open-vm-tools-desktop这个包，而且虚拟机设置里"选项 → 客户机隔离"中的"启用拖放"和"启用复制粘贴"都勾上。

装好之后，从 Windows 资源管理器拖一个文件到虚拟机桌面，或者在两个系统之间复制粘贴文本，都应该是开箱即用的。但我必须说实话，这个功能在我这儿大概只有七成的时候是好用的。

最常见的失效原因是 Wayland。Ubuntu 21.04 之后默认使用 Wayland 作为显示协议，而 open-vm-tools 的桌面集成组件对 Wayland 的支持一直不完整，导致拖拽和剪贴板共享时灵时不灵。排查方法是看当前会话类型：

echo $XDG_SESSION_TYPE

输出wayland的话，改成 Xorg 会话通常就能解决。在登录界面的右下角有个齿轮图标，点开选择"Ubuntu on Xorg"再登录。这个切换是永久生效的，除非你手动改回来。

另一个原因是虚拟机刚开机那几分钟，桌面组件还没完全加载。等一会儿再试，或者手动重启一下服务：

systemctl restart run-vmblock\\x2dfuse.mount

另外拖拽只适合小文件。我试过拖一个 2GB 的镜像文件，进度条走到一半卡死，虚拟机窗口无响应，最后只能强制关机。原因是拖拽走的临时文件和内存缓冲区机制，大文件会把虚拟机内存吃掉。超过几百 MB 的文件，老老实实用前面三种方法。

5.2 HTTP 临时服务与 netcat 应急通道

有时候前面几条路都走不通，比如虚拟机网络模式配置了半天还是不通，或者你只有一个 SSH 会话但没开 SFTP 子系统。这种情况我一般会开一个临时 HTTP 服务救急，因为这个方案只依赖"能用浏览器打开一个网址"这一个条件。

如果方向是从 Windows 传到 Linux，在 Windows 侧放文件的目录里开一个服务：

# 需要 Python 环境 python -m http.server 8080

然后在虚拟机里用浏览器或者 wget 下载：

wget http://192.168.1.10:8080/file.zip

或者用 curl：

curl -O http://192.168.1.10:8080/file.zip

反过来，如果是要把 Linux 上的文件拿到 Windows，就在虚拟机里开服务：

cd /home/user/output python3 -m http.server 8080 --bind 0.0.0.0

Windows 浏览器访问http://192.168.1.100:8080就能看到目录列表并下载文件。--bind 0.0.0.0这个参数不能省，默认只监听 127.0.0.1，外部访问不到。

再极端一点的情况，连 Python 都没有，可以用 netcat 直接传裸流。Linux 侧监听并重定向到文件：

nc -l -p 9000 > backup.tar.gz

Windows 侧用 netcat 的 Windows 版本推送：

cmd /c "nc.exe 192.168.1.100 9000 < backup.tar.gz"

这条路没有任何加密和校验，仅适合你完全信任当前网络环境的临时场景，传完立刻结束进程，不要在后台长期挂着。校验完整性的话，两边各算一次哈希对比：

certutil -hashfile .\file.zip SHA256

sha256sum file.zip

两个值一致才说明传输过程没出错。这一步在很多教程里被省略，但我吃过亏——一次传输中断导致 zip 解压报错，排查了半天才发现是文件本身不完整。

6. 故障排查实录与速查清单

6.1 网络层问题：先分清"不通"和"不能用"

传输失败的问题，我习惯先分两大类：网络层不通，和网络通但服务不可用。这两类的排查路径完全不同，混在一起查会浪费很多时间。

判断方法很简单。在 Windows 上打开命令提示符：

ping 192.168.1.100

通了说明网络层没问题，问题在服务配置上；不通就要回到虚拟机的网络模式去查。桥接模式下 ping 不通，重点看虚拟机的 IP 是不是和宿主机在同一个网段，用ip addr看虚拟机拿到的地址，用ipconfig看宿主机的地址，两个网段对不上就说明桥接没生效，可能是宿主机的物理网卡选错了。NAT 模式下 ping 不通的，检查一下 VMware 的虚拟网卡 VMnet8 在 Windows 的网络连接里是不是被禁用了，这个网卡被禁用或者驱动异常是很常见的原因。

还有一种情况是能 ping 通但连不上服务端口。这时候在虚拟机里确认服务监听地址：

ss -tlnp

如果看到的是127.0.0.1:22这样的形式，说明服务只监听了本地回环，外部当然连不上。需要改配置文件让它监听0.0.0.0。SSH 对应的是/etc/ssh/sshd_config里的ListenAddress和Port，Samba 是smb.conf里的interfaces配置项。

6.2 权限与文件属性类问题

这一类的表现是"文件传上去了但用不了"。最典型的是属主不对，上传后的文件属于 root 或者某个系统账号，你在 IDE 里想保存就被拒绝。共享文件夹的解决方案是挂载时加uid和gid参数；SFTP 的解决方案是确认你登录的用户就是文件的目标属主；Samba 的解决方案是在共享段里配置force user。

第二个常见的是权限位过窄。从 Windows 传过去的文件，如果挂载参数没配好，可能是 600 甚至更小，导致 Web 服务这类以其他用户身份运行的程序读不到。检查一下：

ls -l /home/user/share/

如果是 600 而你需要 644，最直接的办法是在挂载或共享配置里指定 mask，而不是事后逐个 chmod，因为新建的文件还会继承错误的权限。

第三个是 SELinux。CentOS、Rocky、Fedora 这些默认开着 SELinux 的系统上，即使文件权限位看起来是对的，服务仍然可能读不到，因为 SELinux 的上下文标签不匹配。检查状态：

getenforce

如果是 Enforcing，可以看一下具体的拒绝记录：

sudo ausearch -m avc -ts recent

临时排查可以把模式改成 Permissive 验证是不是 SELinux 的问题，但生产环境不要这么干，正确做法是用semanage fcontext和restorecon修正上下文。

6.3 常见问题速查表

下面这张表是我这几年攒下来的，基本覆盖了八成以上的报错场景，遇到问题可以直接对号入座。

还有一个隐蔽的问题单独说一下：上传文件到 Linux 时不修改文件时间这件事，除了前面提到的 scp -p 和 rsync -t，还有一种情况是文件系统本身不支持高精度时间戳。U盘上的 FAT32 文件系统时间精度只有两秒，从这类介质传文件，时间戳必然会有偏差，这不是工具的问题，是文件系统的限制。

注意：如果你在虚拟机上跑的是带文件监听的开发服务器，比如前端的热更新，修改文件时间戳会触发重新编译。批量上传大量文件的时候建议先停掉监听进程，传完再启动，否则可能触发几十次无意义的重新构建。

6.4 我个人的使用习惯与几条经验

最后说说我自己的配置。我现在的日常是共享文件夹打底，把代码根目录挂到/mnt/hgfs/code，IDE 直接打开这个路径；虚拟机里开着一个 Samba 共享，把日志目录和数据库导出目录暴露给 Windows，方便我用图形化工具打开；SSH 服务常开，SFTP 用来传构建产物和部署包，因为这一步需要保留权限和时间戳。

踩过几次坑之后，我养成了两个习惯。第一，任何传输操作之后，对关键文件做一次哈希校验，一行命令的事，能省掉后面半小时的排查。第二，永远不在共享文件夹里存放 node_modules、虚拟环境这类海量小文件目录，宁可多花两分钟复制到虚拟机本地磁盘，也不要忍受那种跨文件系统操作带来的卡顿。

关于后续可以扩展的方向，如果你管理的虚拟机不止一台，可以考虑把 SFTP 传输脚本化，用 scp 加密钥认证写一个批处理，一次把文件推到多台机器上。再进一步，如果团队协作场景更复杂，可以引入持续集成工具，让文件分发这件事彻底从手工操作里消失。不过那是另一个话题了，先把眼前这四种方法用熟，日常九成以上的场景都够用了。