langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-23 04:55:28 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Question: Persistent PermissionDenied Error When Writing private.pem in Dify Docker Deployment #20775

New Issue
Closed
opened 2026-02-21 20:08:55 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 20:08:55 -05:00
Owner
Copy Link
Copy Source

Originally created by @yuluoqingcheng on GitHub (Dec 3, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

N/A

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Deployment method: Docker Compose
Host OS: Linux
Problem DescriptionI'm trying to deploy Dify via Docker Compose, and all containers show Started status in the terminal. However, the Dify API service keeps failing to initialize with the following permission error:
Setup failed: PermissionDenied (persistent) at write => permission denied Context: service: fs path: privkeys/7093bd7a-4c29-4403-b809-ada4ac16c192/private.pem Source: Permission denied (os error 13)

Troubleshooting Steps I've Tried
Fixed the Docker daemon socket permission issue with newgrp docker, which allowed containers to start properly.
Modified the permissions and ownership of the host ./volumes directory
`sudo chown -R 1000:1000 ./volumes
sudo chmod -R 755 ./volumes

Also tried full permissions for testing

sudo chmod -R 777 ./volumes`
Restarted the containers multiple times with docker compose down && docker compose up -d.
Verified the directory status: ls -ld ./volumes shows the owner is magician:magician (UID/GID 1000) with drwxr-xr-x permissions.

Additional Context
The volumes directory is mounted to /app/volumes in the Dify API container.
I pulled the latest main branch code and updated the Docker images, but the error still persists.
Does anyone have ideas on how to fix this permission issue so Dify can write the private key file successfully?

✔️ Expected Behavior

After executing docker compose up -d, all Dify services (including api, worker, web, etc.) should initialize successfully without permission errors. The Dify API service should be able to generate the private.pem file in the privkeys subdirectory under the mounted volumes directory automatically, and the service should run stably in the background. Users can access the Dify frontend normally via http://server-ip and complete subsequent initialization operations (such as administrator account registration).

❌ Actual Behavior

All Dify containers show Started status in the terminal, but the dify-api service fails to complete initialization due to a permission issue. The service throws a PermissionDenied error when attempting to write the private.pem file to the privkeys subdirectory (path example: privkeys/7093bd7a-4c29-4403-b809-ada4ac16c192/private.pem). Even after modifying the ownership and permissions of the host volumes directory (setting to 1000:1000 with 755 or 777 permissions) and restarting the containers multiple times, the error persists. Users cannot access the Dify frontend normally because the core API service fails to start properly.

Originally created by @yuluoqingcheng on GitHub (Dec 3, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version N/A ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Deployment method: Docker Compose Host OS: Linux Problem DescriptionI'm trying to deploy Dify via Docker Compose, and all containers show Started status in the terminal. However, the Dify API service keeps failing to initialize with the following permission error: `Setup failed: PermissionDenied (persistent) at write => permission denied Context: service: fs path: privkeys/7093bd7a-4c29-4403-b809-ada4ac16c192/private.pem Source: Permission denied (os error 13)` Troubleshooting Steps I've Tried Fixed the Docker daemon socket permission issue with newgrp docker, which allowed containers to start properly. Modified the permissions and ownership of the host ./volumes directory `sudo chown -R 1000:1000 ./volumes sudo chmod -R 755 ./volumes # Also tried full permissions for testing sudo chmod -R 777 ./volumes` Restarted the containers multiple times with docker compose down && docker compose up -d. Verified the directory status: ls -ld ./volumes shows the owner is magician:magician (UID/GID 1000) with drwxr-xr-x permissions. Additional Context The volumes directory is mounted to /app/volumes in the Dify API container. I pulled the latest main branch code and updated the Docker images, but the error still persists. Does anyone have ideas on how to fix this permission issue so Dify can write the private key file successfully? ### ✔️ Expected Behavior After executing docker compose up -d, all Dify services (including api, worker, web, etc.) should initialize successfully without permission errors. The Dify API service should be able to generate the private.pem file in the privkeys subdirectory under the mounted volumes directory automatically, and the service should run stably in the background. Users can access the Dify frontend normally via http://server-ip and complete subsequent initialization operations (such as administrator account registration). ### ❌ Actual Behavior All Dify containers show Started status in the terminal, but the dify-api service fails to complete initialization due to a permission issue. The service throws a PermissionDenied error when attempting to write the private.pem file to the privkeys subdirectory (path example: privkeys/7093bd7a-4c29-4403-b809-ada4ac16c192/private.pem). Even after modifying the ownership and permissions of the host volumes directory (setting to 1000:1000 with 755 or 777 permissions) and restarting the containers multiple times, the error persists. Users cannot access the Dify frontend normally because the core API service fails to start properly.
yindo added the 🐞 bug label 2026-02-21 20:08:55 -05:00
yindo closed this issue 2026-02-21 20:08:55 -05:00
yindo commented 2026-02-21 20:08:55 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 3, 2025):

The persistent PermissionDenied error is happening because the Dify API container runs as a non-root user with UID/GID 1001 (dify), but your host volume is owned by UID/GID 1000. To fix this, change the ownership of your storage directory on the host to UID 1001 and set user read/write/execute permissions:

sudo chown -R 1001:1001 ./volumes/app/storage
sudo chmod -R u+rwX ./volumes/app/storage
docker compose down
docker compose up -d

This aligns the host directory with the container user and resolves the permission issue (source, source).

If the error persists, check if SELinux or AppArmor is enforcing extra restrictions (getenforce and aa-status). If so, either adjust policies or switch to Docker named volumes in your docker-compose.yml to bypass host filesystem restrictions (source, source).

If you still see permission errors, try adding this to your API service in docker-compose.yml:

security_opt:
  - seccomp:unconfined

and restart the containers (source).

For more details, see the Dify upgrade guide.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 3, 2025): <!-- Answer --> The persistent PermissionDenied error is happening because the Dify API container runs as a non-root user with UID/GID 1001 (`dify`), but your host volume is owned by UID/GID 1000. To fix this, change the ownership of your storage directory on the host to UID 1001 and set user read/write/execute permissions: ```bash sudo chown -R 1001:1001 ./volumes/app/storage sudo chmod -R u+rwX ./volumes/app/storage docker compose down docker compose up -d ``` This aligns the host directory with the container user and resolves the permission issue ([source](https://github.com/langgenius/dify/issues/28791), [source](https://github.com/langgenius/dify/discussions/28772)). If the error persists, check if SELinux or AppArmor is enforcing extra restrictions (`getenforce` and `aa-status`). If so, either adjust policies or switch to Docker named volumes in your `docker-compose.yml` to bypass host filesystem restrictions ([source](https://github.com/langgenius/dify/discussions/26573#discussioncomment-14589730), [source](https://github.com/langgenius/dify/discussions/23275#discussioncomment-13957543)). If you still see permission errors, try adding this to your API service in `docker-compose.yml`: ```yaml security_opt: - seccomp:unconfined ``` and restart the containers ([source](https://github.com/langgenius/dify/issues/16802#issuecomment-2753173063)). For more details, see the [Dify upgrade guide](https://github.com/langgenius/dify/releases/tag/1.10.1). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/3ff989a9-c14e-4978-81b9-189159225a7b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3ff989a9-c14e-4978-81b9-189159225a7b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3ff989a9-c14e-4978-81b9-189159225a7b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3ff989a9-c14e-4978-81b9-189159225a7b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3ff989a9-c14e-4978-81b9-189159225a7b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3ff989a9-c14e-4978-81b9-189159225a7b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3ff989a9-c14e-4978-81b9-189159225a7b?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20persistent%20PermissionDenied%20error%20is%20happening%20because%20the%20Dify%20API%20container%20runs%20as%20a%20non-root%20user%20with%20UID/GID%201001%20%28%60dify%60%29%2C%20but%20your%20host%20volume%20is%20owned%20by%20UID/GID%201000.%20To%20fix%20this%2C%20change%20the%20ownership%20of%20your%20storage%20directory%20on%20the%20host%20to%20UID%201001%20and%20set%20user%20read/write/execute%20permissions%3A%0A%0A%60%60%60bash%0Asudo%20chown%20-R%201001%3A1001%20./volumes/app/storage%0Asudo%20chmod%20-R%20u%2BrwX%20./volumes/app/storage%0Adocker%20compose%20down%0Adocker%20compose%20up%20-d%0A%60%60%60%0AThis%20aligns%20the%20host%20directory%20with%20the%20container%20user%20and%20resolves%20the%20permission%20issue%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/28791%29%2C%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/28772%29%29.%0A%0AIf%20the%20error%20persists%2C%20check%20if%20SELinux%20or%20AppArmor%20is%20enforcing%20extra%20restrictions%20%28%60getenforce%60%20and%20%60aa-status%60%29.%20If%20so%2C%20either%20adjust%20policies%20or%20switch%20to%20Docker%20named%20volumes%20in%20your%20%60docker-compose.yml%60%20to%20bypass%20host%20filesystem%20restrictions%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/26573%23discussioncomment-14589730%29%2C%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/23275%23discussioncomment-13957543%29%29.%0A%0AIf%20you%20still%20see%20permission%20errors%2C%20try%20adding%20this%20to%20your%20API%20service%20in%20%60docker-compose.yml%60%3A%0A%0A%60%60%60yaml%0Asecurity_opt%3A%0A%20%20-%20seccomp%3Aunconfined%0A%60%60%60%0Aand%20restart%20the%20containers%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/16802%23issuecomment-2753173063%29%29.%0A%0AFor%20more%20details%2C%20see%20the%20%5BDify%20upgrade%20guide%5D%28https%3A//github.com/langgenius/dify/releases/tag/1.10.1%29.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/29098)
yindo commented 2026-02-21 20:08:55 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Dec 4, 2025):

Please read the release log.

@crazywoola commented on GitHub (Dec 4, 2025): Please read the release log.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#20775
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?