企业官网建设流程全解析

把文件从 Windows 塞进虚拟机，几乎是每个折腾虚拟机的人都会撞上的第一道坎。你可能刚装好一台 VMware 里的 Ubuntu，想把自己电脑上的安装包、数据集、源码压缩包传进去，结果发现鼠标拖不动、Ctrl+C 到虚拟机里按 Ctrl+V 没反应、U 盘插上去虚拟机也认不到。网上一搜，"windows上传文件到虚拟机"的方案五花八门，有人推荐装 VMware Tools，有人说用共享文件夹，还有人直接上 SFTP，看完反而更懵。我自己在两个平台上折腾了七八年，从早期 VMware Workstation 10 到现在 17，从 Ubuntu 14.04 到现在 24.04，中间踩过的坑足够写一本小册子。这篇文章就按"四种方法"这个线索，把这四条通道从原理到实操全部拆开讲清楚，包括每种方法适合什么场景、配置时哪一步最容易翻车、参数怎么算、失败了怎么排查。不管你只是偶尔传个几十兆的安装包，还是要长期在宿主机和虚拟机之间同步几十 GB 的数据集，看完都能直接抄作业。

1. 先定方案：四种上传通道到底该选谁

1.1 虚拟机平台先搞清楚，底层能力不一样

在动手之前，有一件事必须先确认：你的虚拟机跑在什么平台上。这不是废话，因为文件通道的实现方式完全取决于这个。

VMware Workstation / VMware Player走的是 VMware Tools + 共享文件夹（HGFS）这套体系，宿主机目录会被映射到 Linux 的/mnt/hgfs/下面，一挂就是持久的。VirtualBox是另一套，叫 Guest Additions + 共享文件夹，挂载点默认在/media/sf_名称。Hyper-V又是第三种，靠"增强会话模式"和 PowerShell Direct 这条带外通道。至于WSL2、云主机这类形态，严格说不是传统虚拟机，但大家平时也按"虚拟机"叫，它们根本没有图形化的拖拽能力，只能走网络。

这个区别为什么重要？因为网上大量的教程是混着写的。你按 VMware 的步骤去 VirtualBox 里找"共享文件夹"菜单，会发现位置和选项名都不一样；你按 VirtualBox 的思路去 Ubuntu 里敲mount -t vboxsf，在 VMware 里只会报错unknown filesystem type 'vboxsf'。我见过太多人卡在这一步，反复重装系统都解决不了，其实就是方案对错了平台。

所以第一原则：先认平台，再选方法。下面这张表是我自己整理的横向对比，你可以直接对着挑。

1.2 选方法的三个判断维度

光看表格还不够，实际选择时我一般按三个问题来筛。

第一问：这台虚拟机以后还要经常传东西吗？如果答案是"要"，那共享文件夹基本是唯一正解，一次配好，以后你在宿主机git clone下来的项目，虚拟机里刷一下就看到了，不用每次重新拷。如果只是装系统时传几个包，那拖拽或者 SFTP 就够了，没必要为了省两分钟去折腾挂载。

第二问：虚拟机里有图形界面吗？如果是 Ubuntu Server 这种纯命令行环境，拖拽和复制粘贴这两条路直接出局，你连桌面都没有，往哪拖？这种情况下网络通道（SFTP/SCP）是绝对主力，一条scp命令解决问题。反过来，如果你跑的是带桌面的 Ubuntu，那拖拽的体验确实爽，但要接受它不稳定的现实。

第三问：宿主机和虚拟机能互相 ping 通吗？这是网络通道能不能用的前提。很多人 SFTP 连不上，第一反应是 WinSCP 有 bug，实际上是虚拟机的网络模式选了 NAT，而宿主机压根没做端口转发。这个问题我在第 4 章会详细讲，包括 NAT、桥接、仅主机三种模式各自的连通性差异和端口转发配置。

把这三点想清楚，四条路里至少有三条你可以直接排除，剩下的那条按我下面的步骤走就行。接下来逐个拆解。

2. 方法一：共享文件夹，一次配置长期受益

2.1 为什么共享文件夹是最值得优先掌握的方案

共享文件夹的本质是：宿主机把一个目录"暴露"出去，虚拟机里通过一层文件系统驱动（VMware 是 HGFS，VirtualBox 是 vboxsf）把它当成一个本地目录挂进来。注意"当成本地目录"这几个字，这跟网络传输完全不是一回事——它不走 TCP/IP，而是走虚拟机工具提供的半虚拟化通道。

这意味着三件事。速度快，实测在 NVMe 固态上，VMware 共享文件夹的读写能跑到 400 MB/s 以上，比千兆网卡的理论上限还高，因为压根不经过网卡。双向，你在虚拟机里改了文件，宿主机那边立刻就是新的，不存在"同步"这个动作。对应用透明，IDE 打开/mnt/hgfs/project跟你打开本地目录没区别，编译、热重载全都正常。

但它有个前提：必须装虚拟机工具。而且这层驱动是"外挂"的，所以会遇到一些原生文件系统不会有的问题，比如权限映射、符号链接支持、inotify 文件监控失效等。这些坑后面 2.4 节专门讲。

2.2 VMware 侧配置流程与关键选项

先说 VMware Workstation。整个流程分两大步：装 Tools，然后建共享。

第一步，装 VMware Tools。现代 Linux 发行版一般推荐装开源版本，别用 VMware 菜单里那个"安装 VMware Tools"挂载的 ISO，界面老、编译容易失败。Ubuntu/Debian 系直接：

sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop sudo systemctl enable --now vmtoolsd

open-vm-tools-desktop这个包别省，它带的才是显示分辨率自适应、剪贴板共享、拖拽这些桌面能力，只装open-vm-tools的话只有共享文件夹能用。装完systemctl status vmtoolsd看一眼，状态是 active 才算成功。CentOS/RHEL 系换成sudo yum install -y open-vm-tools open-vm-tools-desktop。

第二步，在 VMware 里建共享。虚拟机不用关机，但建议先关机再改设置，避免某些版本提示"虚拟机正在运行"。路径是：虚拟机 → 设置 → 选项选项卡 → 共享文件夹 → 选"总是启用" → 添加。这里有两个输入项要注意：

• 主机路径：选宿主机上那个目录，建议路径里不要有中文和空格。我踩过一次坑，路径里带了个空格，Linux 里挂载后目录名被截断，找了半小时才反应过来。
• 名称：这是虚拟机里看到的挂载点名，就用纯英文，比如share、project、data。

有个"只读"勾选框，如果你只需要往里拷东西不打算改，勾上更安全。默认不勾。

第三步，验证。进虚拟机执行ls /mnt/hgfs/，正常应该能看到你刚起的名字。如果没有/mnt/hgfs这个目录，或者目录是空的，别急，进 2.3 节。如果/mnt/hgfs存在但里面没有东西，多半是共享没启用，回 VMware 里确认那个"总是启用"选上了。

2.3/mnt/hgfs是空的怎么办，手动挂载与开机自启

新版本的 Ubuntu 有个变化：/mnt/hgfs这个目录不再自动创建了，因为 HGFS 的自动挂载在 systemd 体系下经常出问题。所以你ls /mnt/hgfs报"没有那个文件或目录"是正常的，需要手动来。

先手动挂一次试试：

sudo mkdir -p /mnt/hgfs sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid=1000 -o gid=1000 ls /mnt/hgfs

.host:/这个写法有点反直觉，它的意思是"宿主机上所有共享的根"，/mnt/hgfs后面会自动出现各个共享名。如果你只想挂某一个共享，写.host:/share /mnt/hgfs也行。

-o allow_other这个参数非常关键。不加的话只有执行挂载的用户（也就是 root）能访问，你用普通用户账号进去会看到"权限不够"，然后误以为是权限配置问题，其实压根是 fuse 的默认限制。uid=1000、gid=1000是把所有文件的属主强制映射成你的普通用户，id -u查一下自己的 uid，一般是 1000，不是的话按实际填。

手动挂载重启就没了，所以要写进/etc/fstab：

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

写完执行sudo mount -a测试，没报错就说明配置对了。这里有个高频翻车点：fstab最后一行的字段之间必须是制表符或空格分隔，而且如果mount -a报错，重启有可能进不去系统（因为 fstab 校验失败会卡在紧急模式）。所以务必先mount -a验证再重启，这一步千万别偷懒。

2.4 VirtualBox 的共享文件夹和 vboxsf 用户组

VirtualBox 的流程类似，但选项名和挂载点都不一样，混着用必翻车。

先装增强功能包：菜单栏"设备" → "安装增强功能"，它会把一个 ISO 挂到虚拟光驱里，进虚拟机手动执行：

sudo mkdir -p /mnt/cdrom sudo mount /dev/cdrom /mnt/cdrom cd /mnt/cdrom sudo ./VBoxLinuxAdditions.run

如果提示缺少编译环境，先装sudo apt install -y build-essential linux-headers-$(uname -r)。装完重启。

然后是共享配置：设备 → 共享文件夹 → 添加。这里有几个选项和 VMware 不同：

• 共享文件夹名称：纯英文。
• 自动挂载：勾上，挂载点会是/media/sf_名称。
• 固定分配：勾上，这样每次开机自动有。
• 只读分配：按需。

关键的在后面。VirtualBox 的共享文件夹默认只允许vboxsf用户组的成员访问，你直接ls /media/sf_share大概率报权限拒绝。解决方案是把自己加进这个组：

sudo usermod -aG vboxsf $USER

加完之后必须注销重新登录，或者直接重启，光执行命令不生效。我第一次弄的时候反复id检查发现自己已经在组里了却还是没权限，就是没重登。

如果你想手动挂到别的位置，命令是：

sudo mount -t vboxsf sharename /mnt/share

注意这里是sharename而不是.host:/，跟 VMware 的写法完全不同，别记混。

2.5 上传后文件只读、时间戳不对，怎么处理

共享文件夹用得多了，一定会遇到两个问题。

第一个是文件变成只读。原因通常是宿主机那边的 Windows 文件权限，或者挂载时没设 uid/gid。先确认挂载参数里有uid=1000,gid=1000，VirtualBox 那边则是确认自己在 vboxsf 组里。还有一种情况：Windows 上那个目录本身是"只读"属性，或者被某个程序占用（比如你开着 Excel 打开着里面的文件），虚拟机这边就写不进去，表现也是只读。这种时候把 Windows 上的程序关掉就行。

第二个是时间戳被改。这个在跨平台场景下特别常见，因为 Windows 用本地时间存文件时间，Linux 默认按 UTC 解释，两边差了 8 小时。你会看到虚拟机里刚拷进来的文件时间是"8 小时前"或者"8 小时后"。共享文件夹模式下这个基本无解，因为文件元数据是宿主机文件系统提供的。但如果你特别在意时间戳，比如做数据版本追溯，那就别用共享文件夹，改用下面第 4 章的传输方式，并且在命令里显式保留时间：

scp -p ./data.tar.gz user@192.168.56.10:/home/user/ rsync -avz --times ./data/ user@192.168.56.10:/home/user/data/ cp -p ./config.ini /mnt/hgfs/share/

-p就是 preserve，保留时间戳和权限。rsync的-a已经隐含了-t，但显式写出来心里更有底。

注意：共享文件夹里尽量不要跑 Git 仓库。HGFS 对文件权限的支持是"假"的，Git 需要区分 644 和 755，共享目录下经常出现整个仓库文件权限乱掉、git status显示一堆无修改的变更。这个坑值得单独记一笔。

3. 方法二：拖拽与复制粘贴，救急可以别当主力

3.1 它到底依赖什么，为什么经常点不动

拖拽和剪贴板共享，看起来是最符合直觉的操作方式，但它其实是所有方法里依赖最多、最脆弱的一个。它需要同时满足：虚拟机有桌面环境、装了带桌面组件的工具包、虚拟化平台的拖拽开关打开、宿主机和虚拟机的显示会话正常通信。四个条件缺一个，表现就是"鼠标拖过去显示一个禁止图标"或者"文件拖进去卡在 99% 然后消失"。

具体依赖是这样的：VMware 下需要open-vm-tools-desktop且vmtoolsd正常运行，同时在 VMware 的"虚拟机设置 → 选项 → 客户机隔离"里把"启用拖放"和"启用复制粘贴"勾上。这两个默认是勾的，但有些安全加固过的镜像会关掉，很多人装完系统发现剪贴板不通用，就是这里被关了。VirtualBox 下则需要 Guest Additions 的桌面组件，配置项在"设备 → 拖放"和"设备 → 共享剪贴板"，有"双向""主机到客户机""客户机到主机"三档可选。

还有一个容易被忽略的点：Wayland 会话。Ubuntu 从 21.04 开始默认用 Wayland，而 VMware 和 VirtualBox 的拖拽实现长期只对 X11 支持良好。如果你的桌面是 Wayland，拖拽很可能完全不工作，剪贴板倒是能用。判断方法是在终端执行echo $XDG_SESSION_TYPE，输出wayland就是它。解决办法是在登录界面的齿轮菜单里切回 Xorg（Ubuntu 叫 "Ubuntu on Xorg"），切完拖拽通常立刻就活了。

3.2 实际使用中的三种典型失败表现

我把这些年遇到的拖拽故障归成三类，基本能覆盖 90% 的情况。

表现一：鼠标变禁止图标，根本放不下。这是拖放功能没启用，或者 Tools 的桌面组件没装。先在虚拟机里执行systemctl status vmtoolsd（VMware）或lsmod | grep vboxguest（VirtualBox）确认服务在跑，再去平台的设置里确认拖放开关是"双向"。如果都正常仍然是禁止图标，八成是 Wayland 的问题。

表现二：小文件能拖，超过 100 MB 就卡死或进度条消失。这是我在 VMware 上遇到最多的问题。拖拽走的是一条模拟的 RPC 通道，不是正经的文件传输协议，没做断点续传，也没有流控。大文件传输过程中虚拟机稍微卡一下、宿主机 CPU 飙一下，连接就断了，而且不会报错，文件就静静地躺在那里不完整。所以我的经验是：拖拽只用于 50 MB 以内的文件，超过这个量就换方法。

表现三：文件拖过去了，但内容是旧的或者空的。这种情况通常出现在你把宿主机上正在被占用的文件往虚拟机拖。比如你刚在 Windows 上用某个工具生成了一个压缩包，进程还没完全释放句柄，拖过去的就是个损坏文件。养成习惯：拖之前先确认宿主机这边文件可以正常复制。

3.3 什么时候该彻底放弃拖拽

我给拖拽的定位很明确：临时的、小体积的、非批量的文件搬运。符合这三条就用它，体验确实最爽，两秒钟搞定。

但只要出现下面任何一种情况，直接放弃，别浪费时间调试：需要在无图形界面的服务器版虚拟机上工作；要传的文件超过 100 MB；需要传几百个小文件组成的目录；需要自动化、写成脚本反复执行；跨平台到云主机或 WSL2。这些场景拖拽全都搞不定，硬试只会让你怀疑人生。

顺带说一句复制粘贴的文本通道。它和文件拖拽是两套实现，有时候拖拽坏了剪贴板还好着。如果你只是想往虚拟机里贴几行命令或者一段配置，用剪贴板比拖文件靠谱得多。注意一个细节：从 Windows 往 Linux 粘文本，换行符是 CRLF，直接粘进 shell 有时候会在命令末尾多一个隐藏的\r，导致命令报奇怪的错。遇到这种情况可以cat > tmp.sh粘贴后dos2unix tmp.sh转一下。

4. 方法三：网络通道，跨平台通用且可脚本化

4.1 先解决连通性：NAT、桥接、仅主机怎么选

网络通道能不能用，取决于宿主机和虚拟机的网络是通的。这一步不搞明白，后面所有配置都是白费。

VMware 默认给虚拟机的是NAT 模式（VMnet8）。它的特点是：虚拟机可以主动访问外网，但宿主机和外网不能主动访问虚拟机，除非你做端口转发。所以你在 Windows 上用 WinSCP 去连 NAT 模式下的虚拟机，是连不上的，必须先去"编辑 → 虚拟网络编辑器 → VMnet8 → NAT 设置 → 添加"，把虚拟机的 22 端口映射到宿主机的一个端口上，比如宿主机的 2222 转到 192.168.x.x 的 22，然后 WinSCP 连127.0.0.1:2222。

桥接模式（Bridged）是把虚拟机直接接到宿主机所在的物理网络，虚拟机会拿到一个跟宿主机同网段的 IP，两边地位平等，互相能 ping 通，也不用手动配端口转发。这是最省事的模式，缺点是会占用局域网的一个 IP，有些公司网络有限制。

仅主机模式（Host-only，VMnet1）只让宿主机和虚拟机互通，虚拟机出不了外网。这个模式在"上传文件"这个场景下反而是最安全的，因为通道完全封闭在宿主机内部，速度也稳定。

我个人的习惯是：开发用的虚拟机一律桥接，需要装依赖包时能直接上网；纯数据处理、注重隔离的虚拟机用仅主机 + Samba，文件传输路径短、不出网、速度快。

虚拟机的 IP 用ip addr或ipconfig查。注意 VMware 的 NAT 网段里，网关是.2，宿主机虚拟网卡是.1，虚拟机一般从.128往后分配。VirtualBox 的 NAT 默认网段是10.0.2.0/24，虚拟机的 IP 常年是10.0.2.15，这个地址是固定的，但宿主机访问不到，同样需要端口转发。

4.2 SFTP 与 SCP：命令行党的首选方案

网络通道里我最推荐的是 SFTP/SCP，理由是：Linux 端几乎零配置，只要装个 SSH 服务就行；Windows 端工具成熟；可以写脚本；能保留时间戳；无图形界面也能用。

服务端（虚拟机里）配置：

sudo apt update && sudo apt install -y openssh-server sudo systemctl enable --now ssh sudo systemctl status ssh

三步搞定。enable是为了开机自启，不然重启后又要手动开。确认服务在监听ss -tlnp | grep :22。

客户端（Windows 侧）三种选择：

• 图形工具 WinSCP：最稳妥，左边是本机目录，右边是虚拟机目录，拖来拖去就是上传下载。连接时协议选 SFTP，主机填虚拟机 IP，端口 22，填 Linux 的用户名和密码。第一次连会弹主机密钥指纹确认，点接受即可。
• 命令行 scp：Windows 10 1809 之后自带 OpenSSH 客户端，直接在 PowerShell 里用。
• Windows Terminal + Tabby：如果你用 Tabby 这类终端工具，它本身内置了 SFTP 面板，左侧点开就能浏览远端文件系统并上传，很适合已经用 Tabby 连 SSH 的人，不用再开第二个软件。

命令行的典型用法：

# 上传单个文件到虚拟机的家目录 scp -P 22 .\toolchain.tar.gz dev@192.168.1.50:/home/dev/ # 上传整个目录（-r 递归） scp -r .\dataset dev@192.168.1.50:/home/dev/data/ # 从虚拟机下载文件到 Windows 当前目录 scp dev@192.168.1.50:/var/log/app.log . # 保留时间戳与权限（-p），大文件加压缩（-C） scp -p -C .\bigfile.bin dev@192.168.1.50:/home/dev/

几个参数值得记住：-P大写是端口，-p小写是保留时间戳，这俩大小写在 scp 里含义完全不同，写错了就是完全不同的行为，别问我怎么知道的。-C是传输时压缩，对文本类文件（日志、源码、JSON）效果拔群，对已经压缩过的 zip、tar.gz 反而更慢，别加。

如果传的是海量小文件或者需要断点续传，scp 就不合适了，换rsync：

rsync -avz --partial --progress ./project/ dev@192.168.1.50:/home/dev/project/

-a归档模式（保留权限时间符号链接），-v显示细节，-z压缩，--partial断点续传，--progress显示进度条。这个组合在传大目录时体验最好，而且中断了重跑只会补差量，不会从头再来。VirtualBox 那边如果只在宿主机和虚拟机之间传，用仅主机模式配 SSH，速度能跑满虚拟网卡，很够用。

提示：rsync的-a会保留宿主机的属主信息，Windows 端的 uid 映射过来可能是乱七八糟的数字。如果只是想传文件不关心属主，可以加--no-owner --no-group --chmod=D755,F644，避免虚拟机里出现一堆奇怪权限的文件。

4.3 Samba：把 Linux 目录挂成 Windows 的网络驱动器

如果你更习惯 Windows 资源管理器那种"我的电脑里多一个盘"的感觉，Samba 是最贴近的。它的效果是：虚拟机里的某个目录，在 Windows 里以\\192.168.1.50\share的形式出现，可以直接复制粘贴、可以用右键菜单、可以被 IDE 当成普通路径打开。

服务端配置：

sudo apt install -y samba sudo mkdir -p /srv/share sudo chown -R dev:dev /srv/share

然后编辑/etc/samba/smb.conf，在文件末尾加一段：

[share] comment = VM Share path = /srv/share browseable = yes writable = yes valid users = dev create mask = 0644 directory mask = 0755

关键是valid users必须跟 Linux 用户对应，writable = yes允许写入。改完设置 Samba 自己的密码（跟 Linux 登录密码是两回事）：

sudo smbpasswd -a dev sudo systemctl restart smbd

Windows 侧打开"此电脑"，在地址栏输入\\192.168.1.50\share，弹出认证框输入用户名密码即可。想让它长期存在就右键"映射网络驱动器"，选个盘符比如 Z:，勾上"登录时重新连接"。

这里有个几乎人人会踩的坑：SMB 协议版本协商。较老的 Linux 或者某些发行版的 Samba 默认最低版本是 SMB1，而 Windows 10/11 早就禁用了 SMB1，结果就是 Windows 报"你不能访问此共享文件夹，因为你组织的安全策略阻止未经身份验证的来宾访问"。解决办法是在smb.conf的[global]段里显式声明：

[global] server min protocol = SMB2 client min protocol = SMB2

重启 smbd 即可。另一个高频问题是防火墙，Ubuntu 如果开了 ufw，要放行：sudo ufw allow samba。

4.4 临时起个 HTTP 服务，最快的单向搬运

有时候你不想配任何持久服务，就想赶紧把一个大文件从虚拟机"拉"到 Windows，或者反过来。这时候 HTTP 是最轻的：

在 Linux 虚拟机里，把要传的文件放到一个目录，然后：

cd /srv/share python3 -m http.server 8000

Windows 浏览器打开http://192.168.1.50:8000就能看到目录列表，点击直接下载。反过来在 Windows 上想给虚拟机发文件，就在 Windows 装个 Python 后同样跑一句python -m http.server 8000，虚拟机里用：

wget http://192.168.1.10:8000/package.deb curl -O http://192.168.1.10:8000/package.deb

这个方法的优点是零依赖、零配置、绝对能通（只要网络通）。缺点是单向、无认证（同网段谁都能下）、传完记得 Ctrl+C 关掉。我一般在装系统后需要批量装几个 deb 包、或者临时取一个日志文件时用这招，非常顺手。

注意：python3 -m http.server默认监听所有网卡，在公共网络环境下别乱开，传完立刻关。

顺带聊聊端口问题。前面说的"主机访问虚拟机网站"，本质和传文件是一回事：都是宿主机主动连虚拟机的某个端口。所以如果你在 NAT 模式下想在 Windows 浏览器里访问虚拟机的 Nginx，就必须做端口转发（宿主 8080 → 虚拟机 80）。这也是为什么很多人共享文件夹配不明白——他们压根不知道自己的虚拟机在 NAT 后面，宿主机够不着。

4.5 Docker 环境的文件上传补充

现在很多人虚拟机里跑的是容器，这时候要传的其实是"进容器的文件"，比传进虚拟机又多了一层。基本思路是两层跳：先按上面任一方法把文件弄到虚拟机，再用docker cp送进容器：

docker cp ./app.conf mycontainer:/etc/app/app.conf docker cp mycontainer:/var/log/app.log ./

如果你在 Windows 上直接跑 Docker Desktop，它底层走的是 WSL2，Windows 磁盘会挂在/mnt/c/之类的路径下，容器里用-v /mnt/c/Users/xxx/data:/data就能直接挂进去，连"上传"这个动作都省了。这也是为什么很多人推荐开发环境用 Docker Desktop——文件共享这件事被平台底层吃掉了。

5. 方法四：镜像与虚拟磁盘，绕开所有驱动问题

5.1 用 ISO 当搬运箱，最笨但最可靠

当你遇到"什么都没装、网也不通、工具也装不上"的绝境时，ISO 是最后的兜底方案。原理很简单：做一张包含你要传的文件的 ISO 镜像，挂到虚拟机的光驱上，Linux 自动加载，然后cp出来。ISO 是只读的，但对"上传"这个单向动作来说完全够用。

在 Linux 上做 ISO（如果虚拟机里已经有文件要导出）：

sudo apt install -y genisoimage genisoimage -o /tmp/data.iso -R -J -V MYDATA /srv/share/

-R开启 Rock Ridge 扩展（保留 Linux 的长文件名和权限），-J开启 Joliet（兼容 Windows 的长文件名），两个都加最保险。做好的 ISO 用任意方式弄到宿主机，然后虚拟机设置里把 CD/DVD 指向它，勾上"启动时连接"和"已连接"。

在 Windows 上做 ISO 更简单，很多压缩软件和刻录工具都支持，或者用 Windows 自带的oscdimg、第三方的 ImgBurn。把文件拖进待刻录列表，输出成 iso 文件即可。

挂载后进虚拟机：

lsblk # 找到光驱设备，一般是 sr0 sudo mkdir -p /mnt/iso sudo mount /dev/sr0 /mnt/iso ls /mnt/iso cp -r /mnt/iso/* /home/dev/data/ sudo umount /mnt/iso

这个方法的价值不在于效率，而在于可靠。它不依赖 Tools、不依赖网络、不依赖任何服务，只要虚拟光驱能用就行。我给它的定位是"装机初期的急救包"。

5.2 把虚拟磁盘映射到宿主机，Windows 直接读写

如果虚拟机是完全关机状态，还有一条更彻底的路：把虚拟机的虚拟磁盘文件映射到 Windows，当成一个本地磁盘来读写。

VMware Workstation 的做法：菜单"文件 → 映射虚拟磁盘"，选虚拟机目录里的.vmdk文件，选一个未使用的盘符，然后可以选"以只读模式打开"或允许读写。映射完成后，Windows 资源管理器里就多出一个盘，你能直接浏览 Linux 的 ext4 分区——这需要 VMware 的驱动支持，但 Workstation 自带。

VirtualBox 的思路不同，需要先把.vdi转换成.vhd（用VBoxManage clonehd命令），再挂到 Windows 的磁盘管理里。稍微绕一点，但也能实现。

几个必须注意的点：

• 映射前虚拟机必须完全关机，不是挂起、不是快照状态。运行中映射会提示文件被占用，强行操作有损坏风险。
• 映射虚拟磁盘期间，绝对不要对宿主机上的文件做大量写入，特别是不要做磁盘整理。我见过有人映射后一边拷文件一边用 Windows 优化驱动器，结果虚拟机文件系统直接损坏，只能重做。
• 如果 Linux 用了 LVM，映射出来后 Windows 看到的是 LVM 物理卷，没法直接浏览，得用专门工具，这条路就不划算了。
• 操作完记得"断开映射"，别让虚拟机带着映射状态启动。

5.3 扩容与容量的实际计算

用虚拟磁盘方案时有个绕不开的问题：空间够不够。这里要理解快照和 thin provision 的关系。

VMware 的.vmdk如果是 thin 模式的，文件大小只反映实际写入的数据量，你在 Windows 里看它是 20 GB，但虚拟机里显示磁盘有 100 GB，这是正常的。映射到宿主机的盘符，容量一般按实际大小算，但剩余可用空间可能不准，因为 Windows 不认识 ext4 的超级块信息，有时候会显示整个磁盘"未格式化"。这时候千万别点"格式化"，一点全都完了。这个提示我建议直接无视，用第三方工具（比如 ext4 读取类的软件）去读，或者干脆换回网络通道。

扩容的话，VMware 用"虚拟机设置 → 硬盘 → 扩展"，输入新容量，但扩完之后 Linux 里的分区和文件系统还得手动扩：

lsblk # 确认磁盘变大了但分区没变 sudo growpart /dev/sda 3 # 假设根分区在 sda3 sudo resize2fs /dev/sda3 # ext4 扩容

如果是 LVM，还要先pvresize再lvextend再resize2fs，三步缺一不可。这套操作有点风险，建议操作前先打个快照。快照这东西，用完记得合并或删除，不然快照链一长，磁盘性能会明显下降，而且虚拟机目录会变得很大。顺手提一句，如果哪天虚拟机启动报"配置信息（注册表中的）不完整或已损坏"，多半是快照或者配置文件状态不一致，先去看虚拟机目录里是不是残留了.lck加锁文件夹，有的话关掉所有 VMware 进程后删掉，往往能救回来。

提示：映射虚拟磁盘这条路我建议只在"虚拟机起不来但里面数据必须抢救"的情况下用。日常传文件还是老老实实用共享文件夹或网络通道，别给自己找麻烦。

6. 常见问题速查与踩坑记录

6.1 高频故障对照表

下面这张表是我这些年攒下来的，基本覆盖了传文件时能遇到的大多数问题，遇到故障先对号入座。

6.2 只能靠踩坑才记得住的经验

第一，共享文件夹别当 Git 工作区。前面提过，这里再强调一次，因为它造成的困惑特别大。HGFS 和 vboxsf 对 Unix 权限位的支撑是模拟的，Git 依赖权限位判断文件模式变更，结果就是git status老显示文件被改过，git diff却是空的。要么把仓库放在虚拟机本地磁盘，要么在共享目录里执行git config core.fileMode false把权限检查关掉。

第二，文件名里带中文、空格、特殊符号，跨系统传输一定会出问题。不是每次，但概率相当高，而且报错信息往往晦涩。养成习惯：传输前把文件名规范化成小写字母+数字+下划线。批量处理可以用 PowerShell：

Get-ChildItem -File | ForEach-Object { $new = $_.Name -replace '[^\w\.\-]', '_' if ($new -ne $_.Name) { Rename-Item $_.FullName $new } }

第三，传大文件前先看磁盘空间。这个听起来像废话，但真的很多人栽在上面。共享文件夹往虚拟机里拷 20 GB 的数据集，拷到一半报"设备上没有空间"，而且因为是通过 fuse 挂载的，报错信息可能只是简单的Input/output error，看不出是空间问题。传之前df -h看一眼，特别是根分区。

第四，虚拟机快照会让磁盘空间莫名其妙变小。你现在有 50 GB 可用，打了个快照，然后往里传了 20 GB 文件，看着还剩 30 GB，但快照本身也在吃空间（因为要保存旧数据块）。传大数据集前最好把不必要的快照删掉。

第五，传输过程别让虚拟机休眠。尤其是长时间传大文件，虚拟机一进休眠，网络通道就断了，scp 会报Connection reset by peer，rsync 虽然有--partial能续，但共享文件夹写入过程中断可能留下不完整文件。传之前把电源设置里的自动休眠关了。

6.3 让传输更稳的几个实用技巧

用 tar 打包再传，别传零散小文件。一万个 1 KB 的小文件，走 SFTP 要建立一万次传输开销，慢得让人怀疑人生。先tar -czf data.tar.gz data/打成一个包，传完再解，速度差距能到十倍以上。这在跨网络传输时尤其明显。

校验完整性，别凭感觉。传完大文件后对一下校验值，一条命令的事，能省掉后端排查半小时：

# Linux 侧 sha256sum data.tar.gz

# Windows 侧 Get-FileHash .\data.tar.gz -Algorithm SHA256

两边的哈希字符串一致，才算真的传对了。我遇到过一次 scp 中途网络抖动，文件大小是对的但内容坏了，解压时报 CRC 错误，从那以后大文件必校验。

长期同步用 rsync，别反复手动拷。如果你需要每天把 Windows 上生成的报表同步到虚拟机处理，写个一行脚本，配合 Windows 的任务计划程序定时跑，比手动操作可靠得多。rsync 的增量特性意味着第二次之后只传变化的部分，几秒钟就跑完。

给传输留一条备用通道。我的习惯是每台虚拟机同时配好共享文件夹和 SSH，两者互不依赖。共享文件夹挂了还能 SSH 进去救，SSH 配错了还能通过共享文件夹进去修配置。这个冗余在关键时刻真的能救命，尤其是你在调网络配置结果把自己关在门外的时候。

关于传文件这件事，我个人最深的体会是：别追求花哨，追求一次配置长期省心。早期我图省事，每次都靠拖拽和临时 HTTP，结果每次传大文件都提心吊胆，传完还要校验半天。后来老老实实给每台虚拟机配了共享文件夹加 SSH 两条通道，配置花了不到十分钟，之后两三年再没为这事操过心。真要给一个优先级，我的排序是：开发用虚拟机走共享文件夹，服务器类虚拟机走 SFTP，装系统初期的急救用 ISO，需要抢救数据时才动虚拟磁盘映射。把这四条路各自的边界摸清楚，以后遇到任何一台新虚拟机，你都能在五分钟内决定用哪种方式，并且一次配通。