· Roon is slow, freezing or won’t start
· Roon won’t start up at all
· System.Exception: FAILED TO MOVE EXISTING DIR TO RESTOREOLDDIR
· I'm reporting something wrong with Roon and although I was able to workaround, it is probably worth fixing.
I, um, did an incorrect NAS procedure and wound up corrupting my Roon installation. Windows 10 fully updated. I reinstalled Roon and tried to restore from a backup. I got this error message, so I completely wiped Roon from the system and reinstalled and again restored from a (3 days prior) backup. Both times when RoonServer and RoonAppliance started up, I got this error message in the RoonServer_log.txt:
03/22 17:25:09 Info: Starting RoonServer v2.62 (build 1641) production on windows
03/22 17:25:09 Info: Local time is 3/22/2026 5:25:09 PM, UTC time is 3/23/2026 12:25:09 AM
03/22 17:25:10 Trace: [roondns] loaded 26 last-known-good entries
03/22 17:25:10 Debug: Init DefaultBackingApi: HttpWebRequest
03/22 17:25:10 Debug: [easyhttp] default backing API HttpClient -> HttpWebRequest. This may cancel all in progress http requests
03/22 17:25:11 Trace: Checking if we are already running
03/22 17:25:11 Trace: Nope, we are the only one running
03/22 17:25:11 Info: Is 64 bit? True
03/22 17:25:12 Critical: Failed to restore backup. Your database may be in a corrupt state. This can most likley be recovered by Roon Support. System.Exception: FAILED TO MOVE EXISTING DIR TO RESTOREOLDDIR: C:\Users\ockers\AppData\Local\RoonServer\SentryCache => C:\Users\ockers\AppData\Local\RoonServer\.restore_old\SentryCache
---> System.IO.IOException: Access to the path 'C:\Users\ockers\AppData\Local\RoonServer\SentryCache' is denied.
at System.IO.FileSystem.MoveDirectory(String sourceFullPath, String destFullPath)
at System.IO.Directory.Move(String sourceDirName, String destDirName)
at Sooloos.Client.ApplicationCommon.CheckForRestore(String[] argv, String lockname)
--- End of inner exception stack trace ---
at Sooloos.Client.ApplicationCommon.CheckForRestore(String[] argv, String lockname)
I was able to resolve this by manually moving the Settings and SentryCache directories around between .restore_old and .restore_on_launch (and deleting .restore_on_launch directory) as follows:
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer$ ls -al
total 40
drwxr-xr-x 10 ockers ockers 4096 Mar 23 00:39 .
drwxr-xr-x 6 ockers ockers 4096 Mar 22 14:53 ..
drwxr-xr-x 3 ockers ockers 4096 Mar 22 15:19 Application
drwxr-xr-x 4 ockers ockers 4096 Mar 22 16:07 Database
drwxr-xr-x 2 ockers ockers 4096 Mar 23 00:39 Logs
drwxr-xr-x 2 ockers ockers 4096 Mar 23 00:39 .restore_old
drwxr-xr-x 4 ockers ockers 4096 Mar 23 00:23 .restore_on_launch
drwxr-xr-x 3 ockers ockers 4096 Mar 22 15:25 SentryCache
drwxr-xr-x 2 ockers ockers 4096 Mar 22 15:38 Settings
drwxr-xr-x 2 ockers ockers 4096 Mar 22 15:38 Temp
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer$ mv SentryCache .restore_old/ <<<<<<==== NO PERMISSIONS ISSUE
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer$ mv Settings/ .restore_old/
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer$ cd .restore_on_launch/
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer/.restore_on_launch$ ls -al
total 16
drwxr-xr-x 4 ockers ockers 4096 Mar 23 00:23 .
drwxr-xr-x 11 ockers ockers 4096 Mar 23 00:41 ..
drwxr-xr-x 3 ockers ockers 4096 Mar 22 16:08 SentryCache
drwxr-xr-x 2 ockers ockers 4096 Mar 22 16:08 Settings
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer/.restore_on_launch$ mv Settings/ ..
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer/.restore_on_launch$ mv SentryCache/ ..
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer/.restore_on_launch$ cd ..
ockers@zinder:~/roon/ockers/AppData/Local/RoonServer$ rm -rf .restore_on_launch/
After restarting the Windows box and logging in, Roon started up normally. I’m listening to it happily now.
I specifically want you to note that there is no permissions issue doing the “mv SentryCache .restore_old/ “ command so I think this is a roon bug. I’m not sure why it reports this exception and I’m asking you to revisit the code to see if there’s anything fishy with the filesystem/directory system calls here:
System.Exception: FAILED TO MOVE EXISTING DIR TO RESTOREOLDDIR: C:\Users\ockers\AppData\Local\RoonServer\SentryCache => C:\Users\ockers\AppData\Local\RoonServer\.restore_old\SentryCache
---> System.IO.IOException: Access to the path 'C:\Users\ockers\AppData\Local\RoonServer\SentryCache' is denied.
at System.IO.FileSystem.MoveDirectory(String sourceFullPath, String destFullPath)
at System.IO.Directory.Move(String sourceDirName, String destDirName)
at Sooloos.Client.ApplicationCommon.CheckForRestore(String[] argv, String lockname)
--- End of inner exception stack trace ---
at Sooloos.Client.ApplicationCommon.CheckForRestore(String[] argv, String lockname)
I realize this all looks a bit strange to you and I didn’t want to have to confess that the entire Roon installation including Roon, RoonServer, RoonGoer, and RAATServer directories, are windows symlink to a UNC share. They appear to Windows to be on C:\ drive but definitely are not, due to a severe lack of disk space on my old Windows mediapc. Additionally, the Roon backups are on a share mapped as R:\ drive, and restored from the same. The NAS is a “Ubuntu 22.04.5 LTS” linux server with samba of course.
Obviously this meant I couldn’t ask for support for this issue. I tried futzing around with oplocks at ChatGPT’s suggestion, including turning off oplocks in samba, but RoonServer won’t even start any brokers if it can’t get an oplock. I also tried fake_oplocks which didn’t help.
# fake oplocks = yes
# oplocks = no
# level2 oplocks = no
# kernel oplocks = no
For the record none of the above oplock stuff helps with Roon. Manually moving the directories around is what sorted it out.
Final improvement suggestion for this ticket is to correct the spelling of “likley” to “likely”.
Thank you
PS If you reboot the NAS (eg for software updates) with Roon running, it corrupts the database of course. I think it’s not worth trying to add disk retries in Roon such that it could recover from having its network disk disappear, since this should never happen.
Hi @James_Ockers,
Thank you for providing such a detailed report and for your honesty about your setup! We also appreciate you catching the “likely” typo - I’ve passed that on to the team for correction.
Regarding the core issue: While we commend your impressive Linux troubleshooting skills to get things running again, we strongly advise against running the Roon Server and its database over a network share via symlinks.
Roon’s database requires high-speed, low-latency local I/O.
A network-mapped setup leaves the database extremely vulnerable to network fluctuations, dropouts, and latency, which is why the database corrupted when the NAS was rebooted.
The file locking issues (Access Denied) you encountered during the restore process are also due to how Windows and SMB handle file locks over a network.
To ensure long-term stability and prevent future database corruption, we highly recommend freeing up space on your local C:</code> drive or installing a dedicated local SSD for the Roon installation, instead of relying on this network workaround.
Thanks again for your feedback and catching the typo.
Hey, @James_Ockers,
Just circling back on this. Have you had a chance to move the Roon Server database off the network share and onto local storage, or free up space on your C: drive so the installation can live on the machine itself? We also wanted to check whether the SMB file lock issues during the restore are still showing up if you try the setup locally. Reply with any updates or questions, thanks!
Hi Alex and Noris,
Thank you for thinking about this and writing me back. I don’t disagree with the idea of freeing up space on C:\ drive so Roon could be installed locally. This is a mediaPC and the guts of it are not upgradeable. Due to Windows and the small-ish C: drive, I’m not able to free up any more space than I already have. I could put an attached USB flash drive or something external, but I’m not sure that would be any faster than the network drive (see performance info below). When Windows 10 is actually EOL and support ends I’ll install Linux on this hardware and then it’ll have plenty of disk space for Roon.
For now it seems to more or less run okay, but I still think there’s something wrong with Roon backup/restore process if restoring from a mapped network drive, which could cause the restore issue I reported above. I guess if no one else has this problem then maybe it’s specific to me, but I saw some other support threads with similar error messages so I’m guessing it’s plausible there could be some gremlins in the code for all this.
There aren’t any SMB file lock issues unless I cause them myself, using ill-conceived (and chatGPT suggested) smb.conf configuration changes. Using the default (natively supported) samba oplocks seems to work fine for Roon.
As for the network fluctuations, dropouts, and latency, I have wired gigabit ethernet and it’s pretty low latency. Roon seems to work okay in this setup, even though it’s very nonstandard. As for relative performance, I think the effective disk I/O for the network share is about 23% slower than the (probably pretty slow) C: drive. The following is as reported by Windows powershell diskspd.exe:
LOCAL C:\ DRIVE
PowerShell 7.5.5
A new PowerShell stable release is available: v7.6.0
Upgrade now, or check out the release page at:
PS C:\Windows\System32> cd $user
PS C:\Users\ockers> C:\DiskSpd\x86\diskspd.exe -d10 -r -w30 -c128M -t4 -o8 testfile.dat
WARNING: Could not set valid file size (error code: 87); trying a slower method of filling the file (this does not affect performance, just makes the test preparation longer)
Command Line: C:\DiskSpd\x86\diskspd.exe -d10 -r -w30 -c128M -t4 -o8 testfile.dat
Input parameters:
timespan: 1
-------------
duration: 10s
warm up time: 5s
cool down time: 0s
random seed: 0
path: 'testfile.dat'
think time: 0ms
burst size: 0
using software cache
using hardware write cache, writethrough off
performing mix test (read/write ratio: 70/30)
block size: 64KiB
using random I/O (alignment: 64KiB)
number of outstanding I/O operations per thread: 8
threads per file: 4
using I/O Completion Ports
IO priority: normal
System information:
computer name: TV
start time: 2026/04/01 13:06:32 UTC
cpu count: 4
core count: 4
group count: 1
node count: 1
socket count: 1
heterogeneous cores: n
active power scheme: Balanced (381b4222-f694-41f0-9685-ff5bb260df2e)
Results for timespan 1:
*******************************************************************************
actual test time: 10.02s
thread count: 4
CPU | Usage | User | Kernel | Idle
----------------------------------------
0| 94.07%| 2.03%| 92.04%| 5.93%
1| 91.89%| 3.74%| 88.14%| 8.11%
2| 90.17%| 4.37%| 85.80%| 9.83%
3| 91.26%| 7.96%| 83.31%| 8.74%
----------------------------------------
avg.| 91.85%| 4.52%| 87.32%| 8.15%
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 2003828736 | 30576 | 190.81 | 3052.96 | testfile.dat (128MiB)
1 | 2596274176 | 39616 | 247.22 | 3955.59 | testfile.dat (128MiB)
2 | 3018326016 | 46056 | 287.41 | 4598.62 | testfile.dat (128MiB)
3 | 2713190400 | 41400 | 258.36 | 4133.72 | testfile.dat (128MiB)
------------------------------------------------------------------------------
total: 10331619328 | 157648 | 983.81 | 15740.90
Read IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 1400700928 | 21373 | 133.38 | 2134.06 | testfile.dat (128MiB)
1 | 1824456704 | 27839 | 173.73 | 2779.68 | testfile.dat (128MiB)
2 | 2109472768 | 32188 | 200.87 | 3213.92 | testfile.dat (128MiB)
3 | 1905131520 | 29070 | 181.41 | 2902.59 | testfile.dat (128MiB)
------------------------------------------------------------------------------
total: 7239761920 | 110470 | 689.39 | 11030.25
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 603127808 | 9203 | 57.43 | 918.90 | testfile.dat (128MiB)
1 | 771817472 | 11777 | 73.49 | 1175.91 | testfile.dat (128MiB)
2 | 908853248 | 13868 | 86.54 | 1384.70 | testfile.dat (128MiB)
3 | 808058880 | 12330 | 76.95 | 1231.13 | testfile.dat (128MiB)
------------------------------------------------------------------------------
total: 3091857408 | 47178 | 294.42 | 4710.65
PS C:\Users\ockers>
MAPPED SAMBA SHARE:
PS V:\> C:\DiskSpd\x86\diskspd.exe -d10 -r -w30 -c128M -t4 -o8 testfile.dat
WARNING: Could not set valid file size (error code: 50); trying a slower method of filling the file (this does not affect performance, just makes the test preparation longer)
Command Line: C:\DiskSpd\x86\diskspd.exe -d10 -r -w30 -c128M -t4 -o8 testfile.dat
Input parameters:
timespan: 1
-------------
duration: 10s
warm up time: 5s
cool down time: 0s
random seed: 0
path: 'testfile.dat'
think time: 0ms
burst size: 0
using software cache
using hardware write cache, writethrough off
performing mix test (read/write ratio: 70/30)
block size: 64KiB
using random I/O (alignment: 64KiB)
number of outstanding I/O operations per thread: 8
threads per file: 4
using I/O Completion Ports
IO priority: normal
System information:
computer name: TV
start time: 2026/04/01 13:13:12 UTC
cpu count: 4
core count: 4
group count: 1
node count: 1
socket count: 1
heterogeneous cores: n
active power scheme: Balanced (381b4222-f694-41f0-9685-ff5bb260df2e)
Results for timespan 1:
*******************************************************************************
actual test time: 10.01s
thread count: 4
CPU | Usage | User | Kernel | Idle
----------------------------------------
0| 91.89%| 2.50%| 89.39%| 8.11%
1| 76.76%| 3.28%| 73.48%| 23.24%
2| 77.07%| 2.18%| 74.88%| 22.93%
3| 77.69%| 4.52%| 73.17%| 22.31%
----------------------------------------
avg.| 80.85%| 3.12%| 77.73%| 19.15%
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 1185480704 | 18089 | 112.92 | 1806.72 | testfile.dat (128MiB)
1 | 2224095232 | 33937 | 211.85 | 3389.60 | testfile.dat (128MiB)
2 | 2249523200 | 34325 | 214.27 | 3428.36 | testfile.dat (128MiB)
3 | 2295005184 | 35019 | 218.60 | 3497.67 | testfile.dat (128MiB)
------------------------------------------------------------------------------
total: 7954104320 | 121370 | 757.65 | 12122.35
Read IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 828047360 | 12635 | 78.87 | 1261.98 | testfile.dat (128MiB)
1 | 1555038208 | 23728 | 148.12 | 2369.94 | testfile.dat (128MiB)
2 | 1581187072 | 24127 | 150.61 | 2409.79 | testfile.dat (128MiB)
3 | 1617362944 | 24679 | 154.06 | 2464.92 | testfile.dat (128MiB)
------------------------------------------------------------------------------
total: 5581635584 | 85169 | 531.66 | 8506.62
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 357433344 | 5454 | 34.05 | 544.74 | testfile.dat (128MiB)
1 | 669057024 | 10209 | 63.73 | 1019.67 | testfile.dat (128MiB)
2 | 668336128 | 10198 | 63.66 | 1018.57 | testfile.dat (128MiB)
3 | 677642240 | 10340 | 64.55 | 1032.75 | testfile.dat (128MiB)
-----------
It’s slower but not that bad! Interestingly it reports less CPU used for the network test. Hopefully the diskspd.exe test is actually representative of the disk performance, lol.
| disk I/O | total IOPS | read IOPS | write IOPS | total MiBPS | read MiBPS | write MiBPS |
|---|---|---|---|---|---|---|
| c: local | 15741 | 11030 | 4711 | 984 | 689 | 294 |
| v: network | 12222 | 8507 | 3616 | 758 | 532 | 226 |
| difference | -3519 | -2523 | -1095 | -226 | -157 | -68 |
| percent | -22.36% | -22.87% | -23.24% | -22.97% | -22.79% | -23.13% |
Anyway I’ll switch the Roon server to Linux later this year and it can run locally.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.