Synology NAS (DSM)

A few things work differently on a Synology than on a normal Linux server. That has nothing to do with Tunetorch, but it often costs time on the first start. This page collects the points almost everyone trips over, and for each tells you how to recognise that this particular point is the problem.

The general installation is under Installing with Docker. Only the differences are here.

Port 5000 is already taken

DSM uses port 5000 for its own web interface. A container that wants the same port doesn't start at all or pushes the NAS's sign-in page aside.

So choose a different port on the host. Inside the container it stays 5000:

    ports:
      - "7999:5000"

You'll then find Tunetorch at http://<NAS-address>:7999. If a reverse proxy sits in front, it has to point to this port too.

The container runs with a different UID

A shared folder on the NAS rarely belongs to 1000:1000. Check the numbers on the host (via SSH or in File Station) and enter them:

    environment:
      TT_PUID: "1026"
      TT_PGID: "100"

On DSM, 1026:100 is a common value (first user created, group users), but not always the right one. What matters is who owns your data folder.

The most important point: shared folders aren't automatically readable for the container

This pitfall costs the most time, and it's the only one where everything looks right while nothing works.

How you notice it: you mount your music collection as /app/import or /app/musik. In File Station and over the network you can read the folder without any trouble, but Tunetorch still finds nothing. The import recognises this and shows a notice instead of starting. If an older version shows “completed successfully, 0 files imported”, it's the same cause.

The reason: DSM controls access to shared folders via its own permission list (an ACL, as on Windows). For that, it sets the folder's normal Linux permissions to “nobody may do anything”. When you access it yourself via DSM, the permission list counts, and everything works. But a program in the container doesn't sign in to DSM; it only has a user number. If the permission list doesn't allow this access, only the normal Linux permissions remain, and those don't let anyone in.

That the folder belongs to you and you can read it says nothing about this. That's exactly what makes the case so stubborn: everything you'd usually check looks fine.

The solution

In DSM: Control Panel → Shared Folder → select your folder → Edit → Permissions. Add the user whose number the container runs as (that's TT_PUID from above) by name and give them at least read permission.

After that, you have to explicitly apply the permission to the subfolders, in File Station via Properties → Permission. Without this second step, only the top level opens, and one level further down it's closed again.

How to check it

Important: check as the user Tunetorch runs as, not as an administrator.

docker exec -u 1026:100 tunetorch ls /app/import

If the folder listing appears, everything is fine. If you get Permission denied, the entry in the permission list is missing, or it wasn't applied to the subfolders.

Without -u the check is pointless. docker exec otherwise runs as root, and root may do anything. You'd always see the folder listing, however the permissions are set.

If it doesn't work via the interface

Alternatively via SSH on the NAS (not in the container, where the collection is only mounted read-only):

sudo chmod o+rX /volume1/<your-folder>
sudo chmod -R g+rX /volume1/<your-folder>

The capital X is intentional. It only passes the right to open on to folders and doesn't make your music files executable.

Ripping CDs: the drive stays invisible

As a rule, you can't use a CD drive on the NAS for ripping CDs. The right lines in the Compose file don't help here either.

How you notice it: Tunetorch doesn't show a drive in the server settings, even though one is plugged in.

The reason: DSM does recognise the drive as a USB device, but it doesn't ship the driver that turns it into a CD drive (/dev/sr0). This is confirmed on a DS1621+ with DSM 7.4, where the driver is missing entirely. Other models very likely behave the same way. Tunetorch reads CDs only through exactly this device.

How to check it

You can do this without SSH via the Task Scheduler: Control Panel → Task Scheduler → Create → Scheduled Task → User-defined script, as user root. Plug in the drive first and enter this as the script:

{
  ls -l /dev/sr*
  find /lib/modules -name "sr_mod.ko*"
  dmesg | grep -i "CD-ROM"
} > /volume1/<your-folder>/drive.txt 2>&1

Run the task once by hand and open drive.txt in File Station:

What you can do instead

Instead of /dev/sr0, DSM only creates a generic device entry for the drive (/dev/sg…). Tunetorch can't use it, and you shouldn't pass it through either: Every hard drive in the NAS has the same kind of entry, and whoever releases it gives the container direct access to your hard drives.

Start-up takes about a minute

On NAS hardware, around a minute passes between starting the container and the first response, because the database is checked and the server starts up. A “Bad Gateway” from the reverse proxy is normal during that time and goes away by itself.

Only if it stays permanently is it worth investigating. First look at the container's log: if only the internal health check shows up there (127.0.0.1, Python-urllib), your request never reached the container. Then the cause lies in front of it (proxy, port forwarding, name resolution) and not with Tunetorch.

Where to go next

Back to the documentation overview