Update to 1.7 (build 710) breaks file attributes

[EVO]

Core Machine (Operating system/System info/Roon build number)

Unraid 6.8.3 (stable) / Intel Xeon / Docker (github steefdebruijn docker-roonserver)

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Wired (Gigabit LAN)

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

SotM sms-200 Ultra - > Matrix X-SPDIF2 -> Holo Audio Spring 2 DAC KTE

Description Of Issue

While the update itself works fine, it trashed my database at first try. Ok, I have backups. Restoring the latest one took a while but after that the Docker didn’t start anymore
(... start.sh line 50: ... permission denied).
I ended up removing everything (docker container and appdata folder), re-installed the Roon docker (which I never had to do before, certainly never caused by a Roon Core update). Roon Core started flawlessly but after a backup-restore (this time I used a 4-day old one, in case the backup itself is wrecked) it told me to restart and it didn’t come up again. Closer look in the appdate folder: file attributes (especially the “x” flag marking a file as executable) were gone. After another loop (reinstalling docker container, restoring backup) I took a look at the temporary folder “.restore_on_launch” before restarting Roon Core. Inside that folder all the “x” attributes were gone, while the not-yet overwritten “originals” had them in place just fine. Since I used the same docker for a long time and didn’t play around with something that affects file attributes in between the last update and now, I assume the backup-restore routine fails to restore original file attributes ( / permissions).
I’m aware that RoonLabs doesn’t officially support a Community-created docker container, but I’m deeply doubting that it is its fault (or Unraid’s or mine) since it worked in previous updates without issue.
Thanks for looking into this.

[dylan (Dylan Caudill)]

Hi @EVO,

Would you kindly use the directions found here and send us over a set of logs using a shared Dropbox link? Thanks!

[EVO]

Hi, uploaded the logs I have and sent the link to you via personal message.

However, further reading (see github page mentioned above under resolved issues) brought me to the conclusion that there was a setup error, after all. Strange that it never popped an issue before, as it should have failed before but it didn’t.

The issue was related to the specific way Unraid handles Docker permissions. And to the fact that the default container path mappings are duplicated for /app and /data (they point to the same physical directory on Unraid). This is obviously what causes a “folding-in-itself” effect and as a result, messed up the attributes / permissions.

The fix for me was to create separate directories (highlighted in yellow):