This issue is related to a problem I and others are having regarding updating steefdebruijn's Roon Server Docker image using Roon's internal updater. This issue is discussed in this thread on the UNRAID forums and in this issue in steefdebruijn's repo.

 

The reason I wanted to post here is because in the discussion about the issue listed above steefdebruijn told me that this problem with updating only happens for users running the container on UNRAID; apparently it works fine on other NAS devices (synology, etc) and on other Linux distro's running Docker. This leads me to believe that there is something about how UNRAID's DockerMan system deals with permissions that is causing the problem, however I don't even really know where to begin looking to fix this issue. 

 

Most of the people running Roon Server on UNRAID are using my docker template, which can be seen here: https://github.com/xthursdayx/docker-templates/blob/master/roonserver.xml

 

 

There are two required mounted volumes: `/mnt/cache/appdata/roonserver/:/app` amd `/mnt/cache/appdata/roonserver/:/data`

and two important but not required volumes: `/mnt/user/Media/Music_library/:/music` and `/mnt/user/Backup/Roon_Backup/:/backup`

 

After updating Roon Server using the internal updater, the container's docker log reads:
```
/app/RoonServer/start.sh: line 50: /app/RoonServer/Server/RoonServer: Permission denied
/app/RoonServer/start.sh: line 34: kill: (11) - No such process
```

which is what leads to believe that the permissions are changing upon update. 

 

Please see a detailed description of the update process and subsequent container failure with logs and screen shots here: https://github.com/steefdebruijn/docker-roonserver/issues/8#issuecomment-714838274

 

Does anyone have a sense of what might be going wrong, or how to best go about troubleshooting this?

follow

I am very interested in this topic as well.  This issue has tripped me up several times and I am hesitant to update.  Should the proper workflow be to backup your database, reinstal the docker then restore the backup?  I would like to get the 1.8 backup!  

1 hour ago, Austin Cooley said:

I am very interested in this topic as well.  This issue has tripped me up several times and I am hesitant to update.  Should the proper workflow be to backup your database, reinstal the docker then restore the backup?  I would like to get the 1.8 backup!  

Hi Austin, in-container updates seem to be working fine for everyone now after I updated the Unraid template. you can either start from scratch using the updated template in Community Apps, or follow the instructions I lay out in this post (see below) to preserve your existing container. It's a bit convoluted but should work. The final option is to backup your database using the internal back up option, scrap your docker container and then rebuild a new one using the updated template. Then you can try to restore the previous backup you made. However I can't promise this will work as I haven't tested this, and I'm not sure if the dividing up of directories that happens with the template will mess up the structure of your previous backup. 

 

Either way I'll be interested to hear what process you try out. Don't feel too bad if you end up losing your backup - I had to completely rebuild all the metadata for my lossless library (>50k tracks) when I was troubleshooting the update process when  1.7 (Build 667) was released and messed up... It happens to the best of us!