推荐在 dockerfile 中用 workdir 指令固定工作目录,使所有基于该镜像的容器默认以此路径为基准,影响 copy、run、cmd 等后续指令,并确保 docker exec 默认进入该路径;若无法修改镜像,可用 --workdir 临时覆盖,但仅作用于主进程且不改变镜像定义。

创建容器时指定工作目录,核心是让后续 docker exec 命令默认落在目标路径下,避免每次都要加 -w 参数。最直接、最可靠的方式是在构建镜像阶段用 WORKDIR 指令固定路径,而不是在运行容器时临时补救。
在 Dockerfile 中用 WORKDIR 明确设置
这是推荐的首选做法。它把工作目录“固化”进镜像,所有基于该镜像启动的容器都会继承这个路径。
-
语法简单:在 Dockerfile 中添加一行
WORKDIR /app即可,路径不存在会自动创建 -
影响范围广:后续的
COPY、RUN、CMD、ENTRYPOINT都以此为基准路径 -
执行命令更自然:运行容器后,
docker exec my-container pwd直接输出/app,ls、cat config.json等命令都按相对路径解析
运行容器时通过 --workdir 覆盖(仅限单次)
如果无法修改镜像(比如使用第三方官方镜像),可在 docker run 时用 --workdir 指定启动时的工作目录。注意:这仅影响容器主进程的初始工作目录,不改变镜像本身的 WORKDIR 设置。
在 Linux 上通过 Docker 运行 OpenClaw,并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 例如:
docker run --workdir /var/www nginx:alpine,容器内nginx进程将在/var/www下启动 - 但
docker exec默认仍沿用镜像定义的WORKDIR,除非你额外加-w - 适合快速验证或临时调试,不适合长期依赖
验证和确认当前工作目录
别假设设置了就一定生效,动手验证更稳妥:
- 查镜像是否带
WORKDIR:docker inspect your-image | grep -i workingdir - 查运行中容器的实际路径:
docker exec your-container pwd - 对比不同命令行为:
docker exec your-container lsvsdocker exec -w /tmp your-container ls,看输出差异
避免常见误区
几个容易踩的坑,提前绕开:
-
不要依赖宿主机当前目录:
docker run不会自动把宿主机的pwd当作容器工作目录 -
WORKDIR 不等于挂载点:即使你用
-v ./data:/app挂载,容器内/app的工作目录仍是/app,但内容来自宿主机 -
command 和 args 不会自动切换路径:就算你在
docker run里写了sh -c "cd /app && ./start.sh",这只是 shell 内部动作,不影响容器全局WORKDIR










