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

docker-init_permissions container hangs during docker compose up -d on latest Dify #21049

New Issue
Closed
opened 2026-02-21 20:10:26 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 20:10:26 -05:00
Owner
Copy Link
Copy Source

Originally created by @lichao4Java on GitHub (Dec 15, 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

1.11.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Description:
I'm trying to deploy the latest version of Dify using Docker Compose, but the docker-init_permissions-1 container hangs indefinitely.

Environment:

Docker version: 25.0.5, build 5dc9bcc

Docker Compose version: v2.18.1

OS: [please fill in your OS]

Steps to reproduce:

Clone the repository:

git clone https://github.com/langgenius/dify.git

Run Docker Compose:

docker compose up -d

Initially got the error:

validating /data/www/dify/docker/docker-compose.yaml: services.worker.depends_on.db_mysql Additional property required is not allowed

Removed the required property:

sed -i '/required: false/d' /data/www/dify/docker/docker-compose.yaml

Ran docker compose up -d again. Most containers started successfully, except docker-init_permissions-1 which hangs indefinitely:

[+] Running 11/12
⠿ Container docker-init_permissions-1 Starting
...

Observed behavior:
docker-init_permissions-1 keeps starting and never finishes, even after 30+ minutes.

Expected behavior:
All containers should start successfully and docker-init_permissions-1 should complete its initialization.

Additional notes:

All other containers (db_postgres, web, api, worker, etc.) start without issues.

Unsure if this is related to permission handling or some initialization script inside the container.

Request:
Please advise how to fix the docker-init_permissions hanging issue or update the Docker Compose file to work with the latest Docker Compose version.

✔️ Expected Behavior

Expected behavior:
All containers should start successfully and docker-init_permissions-1 should complete its initialization.

❌ Actual Behavior

No response

Originally created by @lichao4Java on GitHub (Dec 15, 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 1.11.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Description: I'm trying to deploy the latest version of Dify using Docker Compose, but the docker-init_permissions-1 container hangs indefinitely. Environment: Docker version: 25.0.5, build 5dc9bcc Docker Compose version: v2.18.1 OS: [please fill in your OS] Steps to reproduce: Clone the repository: git clone https://github.com/langgenius/dify.git Run Docker Compose: docker compose up -d Initially got the error: validating /data/www/dify/docker/docker-compose.yaml: services.worker.depends_on.db_mysql Additional property required is not allowed Removed the required property: sed -i '/required: false/d' /data/www/dify/docker/docker-compose.yaml Ran docker compose up -d again. Most containers started successfully, except docker-init_permissions-1 which hangs indefinitely: [+] Running 11/12 ⠿ Container docker-init_permissions-1 Starting ... Observed behavior: docker-init_permissions-1 keeps starting and never finishes, even after 30+ minutes. Expected behavior: All containers should start successfully and docker-init_permissions-1 should complete its initialization. Additional notes: All other containers (db_postgres, web, api, worker, etc.) start without issues. Unsure if this is related to permission handling or some initialization script inside the container. Request: Please advise how to fix the docker-init_permissions hanging issue or update the Docker Compose file to work with the latest Docker Compose version. ### ✔️ Expected Behavior Expected behavior: All containers should start successfully and docker-init_permissions-1 should complete its initialization. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 20:10:26 -05:00
yindo closed this issue 2026-02-21 20:10:26 -05:00
yindo commented 2026-02-21 20:10:26 -05:00
Author
Owner
Copy Link
Copy Source

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

The docker-init_permissions container runs a shell command that recursively changes ownership of the mounted storage directory and creates a flag file to mark completion. If it hangs, it's usually because the chown command is stuck—often due to a very large, slow, or inaccessible volume, or permission issues on the host filesystem.

To troubleshoot, check your host OS and run ls -la ./volumes/app/storage to inspect permissions and ownership. Review the container logs with docker compose logs init_permissions for errors. If your storage is on a network filesystem (NFS, SMB, etc.), chown can hang. Try running chown -R 1001:1001 ./volumes/app/storage manually on the host to see if it completes. If the .init_permissions flag file exists, try removing it and restarting the container. If you find permission errors, fix them on the host before running Docker Compose again.

The container should exit quickly once permissions are set; if it doesn't, the issue is almost always with the storage mount or host permissions, not the container logic itself.
Reference: docker-compose.yaml logic

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 15, 2025): <!-- Answer --> The docker-init_permissions container runs a shell command that recursively changes ownership of the mounted storage directory and creates a flag file to mark completion. If it hangs, it's usually because the chown command is stuck—often due to a very large, slow, or inaccessible volume, or permission issues on the host filesystem. To troubleshoot, check your host OS and run `ls -la ./volumes/app/storage` to inspect permissions and ownership. Review the container logs with `docker compose logs init_permissions` for errors. If your storage is on a network filesystem (NFS, SMB, etc.), chown can hang. Try running `chown -R 1001:1001 ./volumes/app/storage` manually on the host to see if it completes. If the `.init_permissions` flag file exists, try removing it and restarting the container. If you find permission errors, fix them on the host before running Docker Compose again. The container should exit quickly once permissions are set; if it doesn't, the issue is almost always with the storage mount or host permissions, not the container logic itself. [Reference: docker-compose.yaml logic](https://github.com/langgenius/dify/blob/d942adf3b2d701b6458965c070cb4f65042e7ca0/docker/docker-compose.yaml#L661-L697) <!-- 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/d99800f3-e506-4ced-8186-07677084c1c6?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/d99800f3-e506-4ced-8186-07677084c1c6?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/d99800f3-e506-4ced-8186-07677084c1c6?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/d99800f3-e506-4ced-8186-07677084c1c6?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/d99800f3-e506-4ced-8186-07677084c1c6?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/d99800f3-e506-4ced-8186-07677084c1c6?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/d99800f3-e506-4ced-8186-07677084c1c6?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%20docker-init_permissions%20container%20runs%20a%20shell%20command%20that%20recursively%20changes%20ownership%20of%20the%20mounted%20storage%20directory%20and%20creates%20a%20flag%20file%20to%20mark%20completion.%20If%20it%20hangs%2C%20it%27s%20usually%20because%20the%20chown%20command%20is%20stuck%E2%80%94often%20due%20to%20a%20very%20large%2C%20slow%2C%20or%20inaccessible%20volume%2C%20or%20permission%20issues%20on%20the%20host%20filesystem.%20%0A%0ATo%20troubleshoot%2C%20check%20your%20host%20OS%20and%20run%20%60ls%20-la%20./volumes/app/storage%60%20to%20inspect%20permissions%20and%20ownership.%20Review%20the%20container%20logs%20with%20%60docker%20compose%20logs%20init_permissions%60%20for%20errors.%20If%20your%20storage%20is%20on%20a%20network%20filesystem%20%28NFS%2C%20SMB%2C%20etc.%29%2C%20chown%20can%20hang.%20Try%20running%20%60chown%20-R%201001%3A1001%20./volumes/app/storage%60%20manually%20on%20the%20host%20to%20see%20if%20it%20completes.%20If%20the%20%60.init_permissions%60%20flag%20file%20exists%2C%20try%20removing%20it%20and%20restarting%20the%20container.%20If%20you%20find%20permission%20errors%2C%20fix%20them%20on%20the%20host%20before%20running%20Docker%20Compose%20again.%20%0A%0AThe%20container%20should%20exit%20quickly%20once%20permissions%20are%20set%3B%20if%20it%20doesn%27t%2C%20the%20issue%20is%20almost%20always%20with%20the%20storage%20mount%20or%20host%20permissions%2C%20not%20the%20container%20logic%20itself.%20%20%0A%5BReference%3A%20docker-compose.yaml%20logic%5D%28https%3A//github.com/langgenius/dify/blob/d942adf3b2d701b6458965c070cb4f65042e7ca0/docker/docker-compose.yaml%23L661-L697%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/29669)
yindo commented 2026-02-21 20:10:26 -05:00
Author
Owner
Copy Link
Copy Source

@lichao4Java commented on GitHub (Dec 15, 2025):

validating /data/www/dify/docker/docker-compose.yaml: services.worker.depends_on.db_mysql Additional property required is not allowed

what's happen? @dosu.

@lichao4Java commented on GitHub (Dec 15, 2025): validating /data/www/dify/docker/docker-compose.yaml: services.worker.depends_on.db_mysql Additional property required is not allowed what's happen? [@dosu](https://go.dosu.dev/dosubot).
yindo commented 2026-02-21 20:10:26 -05:00
Author
Owner
Copy Link
Copy Source

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

This error happens because the docker-compose.yaml file includes a required: false property under depends_on for services like db_mysql, but Docker Compose v2.18.1 does not support this property—only condition is allowed there. This was introduced by recent changes in the Dify compose templates. To fix it, remove all required: false lines from every depends_on section in your compose file so only condition: service_healthy (or similar) remains. If your compose file is auto-generated, update the template or .env.example and regenerate the file to prevent the issue from coming back. After making these changes, docker compose up -d should work without this validation error.
Reference

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 15, 2025): <!-- Answer --> This error happens because the docker-compose.yaml file includes a required: false property under depends_on for services like db_mysql, but Docker Compose v2.18.1 does not support this property—only condition is allowed there. This was introduced by recent changes in the Dify compose templates. To fix it, remove all required: false lines from every depends_on section in your compose file so only condition: service_healthy (or similar) remains. If your compose file is auto-generated, update the template or .env.example and regenerate the file to prevent the issue from coming back. After making these changes, docker compose up -d should work without this validation error. [Reference](https://github.com/langgenius/dify/issues/28587) <!-- 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/d165660a-a81a-45cc-a88f-06aabd4c78ff?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/d165660a-a81a-45cc-a88f-06aabd4c78ff?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/d165660a-a81a-45cc-a88f-06aabd4c78ff?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/d165660a-a81a-45cc-a88f-06aabd4c78ff?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/d165660a-a81a-45cc-a88f-06aabd4c78ff?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/d165660a-a81a-45cc-a88f-06aabd4c78ff?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/d165660a-a81a-45cc-a88f-06aabd4c78ff?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=This%20error%20happens%20because%20the%20docker-compose.yaml%20file%20includes%20a%20required%3A%20false%20property%20under%20depends_on%20for%20services%20like%20db_mysql%2C%20but%20Docker%20Compose%20v2.18.1%20does%20not%20support%20this%20property%E2%80%94only%20condition%20is%20allowed%20there.%20This%20was%20introduced%20by%20recent%20changes%20in%20the%20Dify%20compose%20templates.%20To%20fix%20it%2C%20remove%20all%20required%3A%20false%20lines%20from%20every%20depends_on%20section%20in%20your%20compose%20file%20so%20only%20condition%3A%20service_healthy%20%28or%20similar%29%20remains.%20If%20your%20compose%20file%20is%20auto-generated%2C%20update%20the%20template%20or%20.env.example%20and%20regenerate%20the%20file%20to%20prevent%20the%20issue%20from%20coming%20back.%20After%20making%20these%20changes%2C%20docker%20compose%20up%20-d%20should%20work%20without%20this%20validation%20error.%20%20%0A%5BReference%5D%28https%3A//github.com/langgenius/dify/issues/28587%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/29669)
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#21049
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?