Normally yes and opening your own case may be a good thing, but they should be aware:
Check if it helps:
Hi! What’s not quite right with Roon?
· None of the above quite fits
None of the above quite fits
· None of these quite match
Tell us what's going on
· Even though it looks like my server (running in a docker image on my QNAP NAS) has been updated to 2.71 I continue to get the update available box whenever I start up the Roon app. If I try to update it again the result is that "There was an error checking for an update".
Tell us about your home network
· AT&T provided router
Thanks for the input but that is far beyond what I am able to tackle to resolve this. I’ve created a post in Support.
Hi @RAB,
Keeping the QNAP on your currently installed build won’t cause any harm. Please do not try to reinstall the Docker hosting RoonServer. The team will merge your report with others describing the same update error on QNAP. Since build 1683 only targets MacOS, there’s no need to update beyond 1680, but we’re investigating this regardless.
Please stand by.
Hi! What’s not quite right with Roon?
· None of the above quite fits
None of the above quite fits
· None of these quite match
Tell us what's going on
· Roon server upgrade fails
Tell us about your home network
· Telus router
Thanks. Hoping that there is a release that will get rid of the annoying, unnecessary pop up soon.
We’re going to merge this report with some related posts that manifest the same underlying symptom on other NAS models and distributions.
The team is working on the underlying problem. Thank you for your patience.
this got fixed then - so it’s weird this is back?
the update is failing (now) because 3 of the files in the TAR archive are symbolic-links instead of hard-links
[admin@myTVS-682 RoonServer]# pwd
/share/RoonServer/app/RoonServer
[admin@myTVS-682 RoonServer]# find -type l -exec ls -l '{}' \;
lrwxrwxrwx 1 admin administrators 17 2026-08-08 09:54 ./Appliance/.roonhost/RAATServer -> ../RAATServer.exe
lrwxrwxrwx 1 admin administrators 20 2026-08-08 09:54 ./Appliance/.roonhost/RoonAppliance -> ../RoonAppliance.exe
lrwxrwxrwx 1 admin administrators 17 2026-08-08 09:54 ./Server/.roonhost/RoonServer -> ../RoonServer.exe
[admin@myTVS-682 RoonServer]#
Hi! What’s not quite right with Roon?
· None of the above quite fits
None of the above quite fits
· None of these quite match
Tell us what's going on
· Hello Roon Support,
I would like to report an issue with the Roon Server automatic update mechanism in the Docker installation.
I am running Roon Server in Docker on a QNAP NAS using the official image:
ghcr.io/roonlabs/roonserver:latest
The persistent Roon installation is mapped to:
/share/RoonServer:/Roon
The server was running Roon 2.70 (build 1671). From the Roon client, the update to 2.71 (build 1683) was detected and downloaded, but the installation consistently failed with:
There was an error checking for an update.
I verified that this was not related to the Docker image itself. The Docker image was already up to date, and recreating the container did not resolve the issue.
I also verified that:
* /Roon was writable;
* there was plenty of free disk space;
* inode usage was negligible;
* renaming/moving directories within /Roon/app/RoonServer worked correctly;
* the downloaded 2.71 package was actually present.
The important finding was that the update had been successfully downloaded and extracted to:
/Roon/app/RoonServer/.update.tmp/RoonServer
and its VERSION file contained:
2.71 (build 1683) production
However, the update was never promoted to the active installation.
As a workaround, I manually completed the staging step by moving:
/Roon/app/RoonServer/.update.tmp
to:
/Roon/app/RoonServer/.update
and then restarted the Docker container.
After the restart, Roon correctly promoted the staged update. The .update directory disappeared and all active VERSION files now report:
2.71 (build 1683) production
The running process also confirms build 1683.
So the workaround was essentially:
1. Let Roon download and prepare the update normally.
2. Verify that .update.tmp/RoonServer/VERSION contains the expected new version.
3. Rename .update.tmp to .update.
4. Restart the Roon Server container.
5. The server completes the update successfully.
This suggests that the download/extraction phase is working correctly, but the automatic update process is failing during the final promotion/installation step.
This is particularly relevant because the same Docker installation worked correctly with previous Roon releases. I therefore expect the automatic update mechanism to be fixed rather than requiring this manual workaround for future releases.
Could you please investigate why the updater is failing at this stage on the current Docker/QNAP installation, and confirm whether this is a known issue with the 2.71 update mechanism?
I would also appreciate a fix in the Roon Server update process so that future releases can be installed normally through the Roon UI, as they were with previous versions.
I can provide additional logs, the Docker Compose configuration, or any other diagnostic information if required.
Best regards,
Andrea
Tell us about your home network
· Unifi infrastructure, UDM Pro, Switches 10gb, QNAP Server and Roon in a docker container
Additional finding – Docker container reports “unhealthy” after updating to Roon 2.71
After completing the update to Roon Server 2.71, I also noticed that the Docker container is reported as “unhealthy” in Portainer, although Roon Server itself is running normally.
The Docker image is ghcr.io/roonlabs/roonserver:latest (image version 1.0.7).
The configured Docker healthcheck is:
grep -ql ‘[R]oonServer.dll’ /proc/[0-9]*/cmdline 2>/dev/null || exit 1
However, the running Roon Server process in 2.71 is now:
/Roon/app/RoonServer/Server/RoonServer
and there is no RoonServer.dll in the process command line.
I confirmed that the healthcheck fails with exit code 1:
EXIT=1
while the container itself remains running with exit code 0 and Roon Server is fully operational.
This appears to be another compatibility issue between the current Docker image/healthcheck and Roon Server 2.71. The healthcheck seems to be looking for the previous RoonServer.dll process signature, while the new 2.71 build is launched as the RoonServer executable.
The healthcheck should presumably be updated in a future Docker image so that a correctly running Roon Server 2.71 container is not reported as unhealthy.
In the meantime I’ll use in my composer:
healthcheck:
test: ["CMD-SHELL", "grep -ql '/Roon/app/RoonServer/Server/RoonServer' /proc/[0-9]*/cmdline 2>/dev/null || exit 1"]
interval: 30s
timeout: 10s
start_period: 120s
retries: 3
For people having the same problem (or similar problem) from 2.70 to 2.71, I’ve open a case,
[Now merged into the tracking topic.]
and I’ve some workarounds to fix the situation in the meantime:
Hope this helps
Andrea
Hey @Alan_Sparks,
Thanks for the update and additional information. We have a ticket in with our development team to take a closer look into this.
In the meantime, if you’d rather not stay on your current build:
@Fabien_Fuster’s tar wrapper works, several of you have confirmed it, but we’re going to stop short of recommending it as our official guidance, since it replaces a system binary inside the container and gets wiped whenever the container is recreated. No criticism of the script itself; it’s a sharp piece of work.
The cleaner route, if you’re comfortable at the command line on the NAS itself, is to extract the update on the QNAP host rather than inside the container, where chmod behaves normally. Roughly:
- Back up your database first (Settings → Backups), and confirm the backup completed.
- Stop the Roon Server container in Container Station.
- On the NAS host, download
RoonServer_linuxx64_207101683.tar.bz2from our production update path and extract it over your install directory — the host-side path behind the container’s/Roon/app/RoonServerbind mount, e.g./share/RoonServer/app/RoonServer. - Start the container again.
We’ll be in touch with next steps as soon as the team takes a closer look. Thank you!
Hi! What’s not quite right with Roon?
· None of the above quite fits
None of the above quite fits
· None of these quite match
Tell us what's going on
· I am unable to update the Roon Server from 2.70 to 2.71 on any of my endpoints. It tells me there is an "error checking on an update". The software updates without issue. I am using a QNAP TVS-471. I have already had to update my core to load into a "package?" on my NAS.
Tell us about your home network
· TVS-471, which communicates with the network through an ASUS BE-98 through LAN, and the BE-98 sends data throigh LAN or through WiFi, depending on the endpoint.
Thanks, that addition to my roonserver compose has removed that pesky container error on Synology after upgrade to 2.71 - 1683
Hi everyone,
The team has a ticket in the pipeline. Please stand by and we’ll share more information about a timeline to resolution here as it becomes available.
This shouldn’t continue to be an issue with future updates.
2 Likes
Hi @mwaggener,
You’ve encountered a known issue for which the team has a fix in the pipeline. We’re going to merge your thread into the main tracking thread so you can see updates from the team and suggested workarounds from other users.
Sorry I’m late to the thread here. I’m actively working on this and will hopefully have something “soon”. I’ve reproduced this on my QNAP.
1 Like
I’ve finally narrowed this down and posted a proposed fix here: Work around vendor kernels whose syscall 452 is not fchmodat2 (RRD-2830) by decriptor · Pull Request #31 · RoonLabs/roon-docker · GitHub
(I used AI to clean up my response)
“The PR has more details, but the short version: QNAP’s kernel has a few private syscalls on numbers that later versions of Linux assigned to new official syscalls. The glibc in our Docker image is new enough to use one of those — syscall 452, fchmodat2. That’s normally fine: if the syscall doesn’t exist, the kernel returns “not implemented” and glibc falls back to the old path. On QNAP, 452 does exist, but it’s a different function. The kernel returns “Bad address” instead, glibc doesn’t fall back, and tar treats that as a hard failure. That’s what breaks install and self-update.”
I’m hoping to get this wrapped up soon and publish a new image tomorrow.
3 Likes
I published a new image: v1.0.8
It has both the health check fix and the QNAP chmod fix in it. Thanks to Toastyice ( Toastyice · GitHub ) for the PR to help fix the health checks.
I have it up and running on my QNAP and it seems to be working correctly. If anyone runs into problems with this release ping me.
4 Likes