Hello all,
Happy new year to whoever reads this 🙂

@Sporiff Late last year I followed the instructions on the Develop branch to install Funkwhale using Docker, as you suggested on GitLab.

My compliment on the rework you did there - it's a big big improvement! While going through the process from scratch (I wiped everything I had and started over), I noted a few points that weren't entirely clear to me or didn't go 100% smooth. I just wanted to share them here as it might help for further improvements.

3.1 Pull the containers to download all the required services
docker-compose pull

The syntax in the install guide is based on Compose standalone (with the dash), however, that's no longer a supported scenario.

Instead, Compose v2 uses a space.

2.5 Open the .env file in a text editor

Instructions are clear. I had some doubts, however, about the env file itself:

# If you're tweaking this file from the template, ensure you edit at least the
# following variables:
...
# Additional options you may want to check:
# - MUSIC_DIRECTORY_PATH and MUSIC_DIRECTORY_SERVE_PATH if you plan to use
# in-place import

And so I check this section:

# In-place import settings
# You can safely leave those settings uncommented if you don't plan to use
# in place imports.

But I do plan to use in-place imports as my files will be stored on the NAS, separate from Funkwhale. So I go on:

# Typical docker setup:
# MUSIC_DIRECTORY_PATH=/music # docker-only
# MUSIC_DIRECTORY_SERVE_PATH=/srv/funkwhale/data/music

As per the docs

On Docker setups the value of MUSIC_DIRECTORY_PATH may be different from the actual path on your server

  • In my compose file, can I adjust the first (source) and/or the second (target)? I now have it working so I guess I did figure it out (that MUSIC_DIRECTORY_PATH should be the same as the volume specified in the compose file and that MUSIC_DIRECTORY_SERVE_PATH should be the actual location), but I think it'd be helpful to make this a bit clearer in the env file template. I would suggest:

# In-place import settings
#Even if you don't plan to use in place importyou can safely leave those settingsactive (uncommented)if you don't plan to use
# in place imports.

(because currently this first line that says 'leave uncommented' contradicts the comment after the referenced line, which says 'stays commented' for non-docker set-ups)

# Typical docker setup:
# MUSIC_DIRECTORY_PATH=/music #docker-onlyvolume specified in the compose file
# MUSIC_DIRECTORY_SERVE_PATH=/srv/funkwhale/data/music #location of the folder on your drive

The path on your server from where Funkwhale places picks up files from in-place imports.

(because, if I understand correctly, in-place import actually doesn't place/copy any file, but rather puts existing file locations in the database)

On Docker installations, we recommend you use the default change the default value to /music path.

(because /music is not the default path in the template file, but this: MUSIC_DIRECTORY_PATH=/srv/funkwhale/data/music)

Though all in all I'm thinking it might be better to just remove the default alltogether and tell people to uncomment if needed (only in case of Docker)?

To do this, you need to add the directory to the api and celeryworker and front blocks in your docker-compose.yml file

(IIRC I was told in the Matrix channel that also front needs access to the music volume - that's in any case how I got it working now)

  • rather than repeating the volumes in each of the three blocks, isn't it possible to declare the necessary volumes once and reference them in the three blocks? That'd be a bit less error-prone.
  • I also noted back when doing this that "I can add my in-place import location to docker-compose.yml as volume (to the 3 containers) but editing the .env file (/srv/funkwhale/data/music --> /NAS/music) has the same effect & is easier"

- type: bind
source: /media/nfsshare
destination: /srv/funkwhale/data/music/nfsshare

That didn't work for me and, again, IIRC, I was told in the Matrix channel that this wasn't correct. I now have just removed this because the NFS share is mounted to a folder, and I've just referenced that in the .env file as mentioned above.

2.3 Reduce the permissions on your .env file to 600. This means that only your user can read and write this file

As I went through the whole instructions using sudo (due to Docker permissions), this prevented me from sourceing the .env file while updating. Maybe this'll be addressed already by #2025.

I'm sorry for this wall of text. Really they're relatively minor points, but I wanted to share them anyway.

    Hi keunes, thanks for this detailed writeup! This is really useful.

    The syntax in the install guide is based on Compose standalone (with the dash), however, that's no longer a supported scenario.

    Okay, that's an easy enough fix!

    Instructions are clear. I had some doubts, however, about the env file itself:

    I think you're right, we need to have a cleanup of the language and instructions included in that file. There are a few config options not listed and some confusing comments. I'll put in an issue for me to go through this.

    (because, if I understand correctly, in-place import actually doesn't place/copy any file, but rather puts existing file locations in the database)

    This is correct. I can update this language to be clearer about exactly what the mechanism does.

    Though all in all I'm thinking it might be better to just remove the default alltogether and tell people to uncomment if needed (only in case of Docker)?

    Where possible, this approach is best. I'll need to just check and see if removing it would have any repercussions. In the majority of cases, we want the user to not have to configure anything.

    rather than repeating the volumes in each of the three blocks, isn't it possible to declare the necessary volumes once and reference them in the three blocks? That'd be a bit less error-prone.

    It should be possible to use a variable for this. Let's try it!

    I also noted back when doing this that "I can add my in-place import location to docker-compose.yml as volume (to the 3 containers) but editing the .env file (/srv/funkwhale/data/music --> /NAS/music) has the same effect & is easier"

    Good point! Easier is always better.

    As I went through the whole instructions using sudo (due to Docker permissions), this prevented me from sourceing the .env file while updating. Maybe this'll be addressed already by #2025.

    You know, I'm not actually sure sourceing this file is required. As far as I remember, docker-compose will always look for a .env file in its directory and read values from there. In my years of running a Docker setup, I don't think I've sourced the .env file once, so this may be entirely unneeded.

    • gcrk replied to this.
      6 days later

      Sporiff Okay, that's an easy enough fix!

      Its not. Those tools are slightly different and we should not advice users to mix them up. Please don't just remove the dash!