fix(docker): pre-create /home/deepseek/.deepseek to avoid permission denied on first run#1699
Conversation
…denied on first run Closes Hmbown#1684
There was a problem hiding this comment.
Code Review
This pull request updates the Dockerfile to create a .deepseek directory in the user's home directory with appropriate ownership. The review feedback suggests using the install command to more concisely create the directory while simultaneously setting restrictive permissions (0700) to enhance security for sensitive data.
| && useradd --create-home --shell /bin/bash --uid 1000 --gid 1000 deepseek \ | ||
| && mkdir -p /home/deepseek/.deepseek \ | ||
| && chown -R deepseek:deepseek /home/deepseek/.deepseek |
There was a problem hiding this comment.
Using the install command is a more concise and idiomatic way to create a directory with specific ownership and permissions in a single step within a Dockerfile. Additionally, since the .deepseek directory stores sensitive information such as API keys (as noted in the README), it is a security best practice to restrict its permissions to the owner only (e.g., mode 0700).
&& useradd --create-home --shell /bin/bash --uid 1000 --gid 1000 deepseek \
&& install -d -m 0700 -o deepseek -g deepseek /home/deepseek/.deepseek
Collapse the mkdir + chown pair into a single `install -d` invocation that sets ownership and 0700 permissions atomically. The .deepseek directory stores API keys per the README, so restricting access to the owner is appropriate. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Fixed in a6c7c83 — collapsed mkdir + chown into |
|
Thanks for this. The Docker permission fix was harvested into v0.8.39 via #1734 and credited in the changelog, so I am closing this PR to keep the queue clean. If the latest GHCR image still fails with the README named-volume command, please reopen or file a fresh repro and we will treat it as a v0.8.40 blocker. |
Summary
The non-root
deepseekuser couldn't write/home/deepseek/.deepseek/tasks/runtime/threadson first run inside Docker, failing withPermission denied (os error 13). The Dockerfile created the user and switched to it before any process ever touched the home subdirectory; the runtime then hit a fresh/home/deepseekowned by root (because the user's HOME was newly created with default perms but bind-mounted volumes adopted root ownership).Pre-create
/home/deepseek/.deepseekwithdeepseek:deepseekownership in the sameRUNthat adds the user, so any subsequent volume mount or process write lands on a directory the runtime user can write to.Why this matters
Reporter @[issue1684_user] in #1684 reported the bridge crashing on first launch in Docker before any thread could be created. The fix is contained to the user-setup section of the Dockerfile (same
RUNthat callsuseradd), keeps the image layer count unchanged, and doesn't touch the runtime.Fixes #1684