docker cp 报 lstat no such file：文件在家目录，命令却从根目录运行

执行 docker cp port01.txt web001:/tmp/port01.txt 后，报错指向本地文件，例如 lstat //port01.txt: no such file or directory。即使 docker ps -a 能列出 web001，也不能证明源文件存在。此时应先核对运行 Docker CLI 的目录和文件路径。

这篇讨论 Linux、WSL 或 Docker Desktop 环境中，将本地普通文件复制进已有容器的场景。docker cp 是运行期文件复制；它不会按 Dockerfile 所在目录查文件，也不使用镜像构建的上下文和 .dockerignore。

相对路径取决于 Docker CLI 的当前目录

在执行复制命令的同一个终端位置查看路径。下面是只读检查示例：

pwd
ls -l -- ./port01.txt

如果 pwd 显示 /，port01.txt 会指向根目录下的文件；稍后在家目录运行 ls 看见同名文件，并不能证明刚才的源路径正确。定时任务、CI 步骤或新终端也可能采用不同工作目录，应以实际执行复制时的位置为准。

lstat 后面的路径能帮助判断 Docker 在找哪一端。报错指向本地源文件时，先确认大小写、文件是否创建成功、当前用户能否读取，以及路径是否来自另一套文件系统。不要因为目标容器存在，就转去重建它。

Docker Desktop 场景中，要区分 Windows 路径、WSL 中的路径和 Docker 后端虚拟机的路径；本地源文件应能被正在运行的 Docker CLI 访问。选了远程 Docker context，也不会把未带容器前缀的本地源路径自动解释成远程 daemon 主机上的目录。

用确认过的完整路径复制

下面是普通文件的复制示例，用户目录、容器名和目标都需要替换：

docker cp /home/example/port01.txt web001:/tmp/port01.txt

它假设本地源文件可读，容器内 /tmp 已存在，目标没有需要保留的同名文件。包含空格的路径应完整加引号。也可先进入实际源目录后使用相对路径，但脚本中使用确认过的绝对路径通常更容易看清依赖。

本地普通文件路径与容器路径通过冒号区分。web001:/tmp/port01.txt 指向容器内部，源路径没有这段前缀，就仍在 CLI 本地一端。拼错容器名是另一个问题，修正源文件后还需核对目标名称。

不要为了制造一个 /port01.txt 就切换成 root 或放宽整个根目录权限。文件本来位于用户目录时，直接使用正确路径即可；如果文件创建曾报 Permission denied，应先确认它是否真的创建成功。

容器停止不妨碍普通文件复制

docker cp 可以对运行中或停止的容器复制文件。Created 或 Exited 本身不是这类本地源文件缺失的解释，无须仅为复制普通文件先启动应用。

目标父目录不存在时，Docker 不会替你创建整条目录路径。目标文件已存在则可能被覆盖；复制前检查目标用途并保留需要恢复的原文件，不能直接覆盖运行中的应用配置或凭据。

复制到容器的文件默认归属与源端保留所有者的行为也要区分。应用依赖特定用户读取时，复制完成后按实际要求核对权限和所有者，不要给所有文件统一设置任意用户可写。涉及运行时挂载、特殊文件或文件系统限制的失败，需要按具体目标继续排查，不能都归因于当前目录。

复制完成后，还要核对内容与用途

成功标准是目标容器中出现了预期文件，内容与源文件一致，使用它的应用账户具备所需权限。文件存在不代表应用已重新读取配置，也不代表容器重建后文件会保留。

一次性诊断文件可以通过 docker cp 传入；长期配置应写入受维护的镜像、挂载或部署配置。否则容器重新创建后，手动复制的文件可能丢失。使用镜像已有工具或应用自己的检查核对内容，精简镜像没有 shell 不是复制失败的证据。

若复制覆盖了原文件，按事先保存的副本恢复，并用应用正常的加载方式确认状态。只删除本次明确创建的诊断文件，不要把容器里的整个目录当作临时资料清理。