Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

To create volume folders or not to #125

Open
75th opened this issue Jul 19, 2024 · 3 comments
Open

To create volume folders or not to #125

75th opened this issue Jul 19, 2024 · 3 comments

Comments

@75th
Copy link

75th commented Jul 19, 2024

I have the exact same problem as #24, but with a twist. I'm trying to use the docker-compose file in Container Manager in Synology DSM. If I create the data folders ahead of time, I get the same "Waiting for confirmation of MySQL service startup" loop as in #24, which says to simply not create them ahead of time. But if I don't, I get this error:

Bind mount failed: '/volume1/Ampache/data/mysql' does not exists

([sic] on "exists")

I went looking to learn more about Docker stuff to understand this issue, and I immediately found this:

Volumes have several advantages over bind mounts:

So the docs say volumes are an alternative to bind mounts, but I'm getting bind mount errors when trying to use volumes. At this point I threw up my hands and came here. By all means tell me if I should go bug the Synology forum, but the Synology forum is pretty useless in my experience, and I thought maybe there's a chance this is still Ampache-specific.

Here's the docker-compose YAML I'm using. Changed a port and omitted the last line, which DSM didn't like.

My docker-compose
version: '3'

services:
  ampache:
    image: ampache/ampache:latest
    container_name: ampache
    restart: unless-stopped
    ports:
      - 50180:80
    volumes:
      - ./data/config:/var/www/config
      - ./data/log:/var/log/ampache
      - ./data/media:/media
      - ./data/mysql:/var/lib/mysql
@RulerOf
Copy link

RulerOf commented Jul 19, 2024

I got the email from your initial act of necromancy. 😉

Not sure what the "right" way to resolve this is, but my suggestion would be to populate the bind mount folder from the container image.

Use a bind mount instead of a volume, but extract the /etc/mysql contents into it before creating the container. Some convoluted invocation of tar should be able to accomplish this.

My guess here is that Synology does some kind of custom volume handling code that doesn't quite behave the way it's supposed to.

@kuzi-moto
Copy link
Member

Did you set the permissions of ./data/mysql correctly? I would try using UID and GID 999 and see if there's any difference.

@75th
Copy link
Author

75th commented Jul 21, 2024

The permissions change seems to have done it! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants