Update docker-compose.mysql.yml

[Tontonjo]

Corrected path in container to match what Koel is expecting as mountpoint:
koel:doctor
Image storage directory public/storage/images is not readable/writable ERROR

Summary by CodeRabbit

• Chores
  • Updated image storage directory configuration to optimize file organization and serving within the application environment.

[coderabbitai]

📝 Walkthrough

Walkthrough

Updated the Docker Compose configuration for the Koel service to mount the image storage volume to the web-accessible public directory instead of the internal Laravel storage directory, changing the container mount path from /var/www/html/storage/app/public/images to /var/www/html/public/storage/images.

Changes

Docker Compose Storage Configuration

Layer / File(s)	Summary
Image storage volume mount path docker-compose.mysql.yml	Updated the koel service's image_storage volume to mount at /var/www/html/public/storage/images for web-accessible serving instead of /var/www/html/storage/app/public/images.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐰 A rabbit hops through compose files bright,
One path redirects to public light,
Images now served from the right place,
Storage flows with elegant grace! 📦✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title is vague and generic, using only 'Update docker-compose.mysql.yml' without specifying what change was made or why it matters.	Consider a more descriptive title like 'Fix image storage path in docker-compose.mysql.yml' or 'Correct Koel image storage mount point' to clarify the purpose of the change.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docker-compose.mysql.yml`:
- Line 16: The compose mount uses the wrong target path causing Koel to
read/write images in the wrong place; update the volume mapping for
image_storage so it mounts to Koel’s internal storage path
/var/www/html/storage/app/public/images (replace the current
/var/www/html/public/storage/images target), ensuring the image_storage volume
name remains unchanged and the service that declares this volume continues to
reference image_storage.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a0e0c32e-5495-407a-8ce6-cad20a994179

📥 Commits

Reviewing files that changed from the base of the PR and between 17e4c70 and 3e6641b.

📒 Files selected for processing (1)

• docker-compose.mysql.yml

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Restore the image_storage mount target to Koel’s internal storage path.

This change points the volume to /var/www/html/public/storage/images, but the image and init flow persist/read images at /var/www/html/storage/app/public/images. Mounting the wrong target breaks the storage contract and can cause unreadable/unwritable image storage or lost persistence behavior after init/migrations.

Suggested fix

-      - image_storage:/var/www/html/public/storage/images
+      - image_storage:/var/www/html/storage/app/public/images

Based on learnings: Dockerfile creates/declares /var/www/html/storage/app/public/images as the image-storage volume path, and CHANGELOG documents this exact compose mount target for upgrades.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	- image_storage:/var/www/html/public/storage/images
	- image_storage:/var/www/html/storage/app/public/images

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docker-compose.mysql.yml` at line 16, The compose mount uses the wrong target
path causing Koel to read/write images in the wrong place; update the volume
mapping for image_storage so it mounts to Koel’s internal storage path
/var/www/html/storage/app/public/images (replace the current
/var/www/html/public/storage/images target), ensuring the image_storage volume
name remains unchanged and the service that declares this volume continues to
reference image_storage.

[phanan]

Thanks for reporting this — you found a real bug, and it turned out to be worse than the compose file.

koel's release archive ships public/storage as an absolute symlink into the directory the release runner built in:

koel/public/storage -> /home/runner/work/koel/koel/storage/app/public

That resolves nowhere in the container, so koel can neither read nor write uploaded images and koel:doctor reports exactly the error you saw. It affects every Docker image and every standalone tarball install, not only the mysql compose setup. koel:init cannot repair it either: storage:link checks file_exists(), which is false for a dangling symlink, so it tries to create one and fails on the path already there.

Fixed in #229 by repairing the link at build time, which covers all three compose files and any hand-rolled docker run, and keeps images in the volume the VOLUME declaration already points at — so existing installations don't lose theirs. The root cause is fixed in koel/koel#2644 so future releases ship a portable archive.

Closing this in favour of #229. Thank you for the report.

[phanan]

Correcting something I got wrong above.

I wrote that koel:init cannot repair the link because file_exists() is false for a dangling symlink, so storage:link fails on the existing path. The first half is right, the conclusion is not. Laravel's StorageLinkCommand falls through that guard and then hits an is_link() branch which deletes the link before recreating it:

if (file_exists($link) && ! $this->isRemovableSymlink($link, $this->option('force'))) {
    // skipped for a dangling link, since file_exists() is false
}

if (is_link($link)) {
    $this->laravel->make('files')->delete($link);
}

So koel:init does repair a dangling link — it just recreated it as another absolute one, which is why the problem kept coming back. The reason the published image is broken is simpler than I said: the image is built without ever running koel:init, so nothing repairs the link that came out of the tarball, and koel:init is skipped at runtime when no .env is mounted or SKIP_INIT is set.

None of this changes the fix or the diagnosis of the underlying bug — the archive genuinely ships a link into the release runner's filesystem. I just described the repair path incorrectly.