· ROCK database reset to empty + attached music storage reformatted
Tell us about your home network
· Roon Optimized Core Kit, serial #94C691AEBD45 RoonOS 2.1 (build 271) production RoonServer 2.70 (build 1671) production at the time of the incident Wired Ethernet, static local network, no Wi-Fi involved Local music storage: a ~1TB USB SSD (Micron/Crucial X8 family) attached directly to the ROCK, holding ~700GB of local files, separate from the ROCK's internal boot/system storage Streaming service: Qobuz
Roon support report: ROCK database reset to empty + attached music storage reformatted, following a “Database & Settings: Not Ready” episode
Summary
My Roon Optimized Core Kit (ROCK) recovered from a “Database & Settings: Not Ready” state by resetting to a completely empty, first-run library (0 tracks) rather than repairing or preserving the existing one — and the ~1TB USB SSD holding my local music library (~700GB of files) was subsequently found reformatted and empty, despite no explicit “erase this drive” action taken deliberately. I’m reporting this because the severity (apparently permanent loss of a personal music library, with no strong warning before the destructive step) seems like something Roon should know about regardless of the outcome for my specific case.
System
Roon Optimized Core Kit, serial #94C691AEBD45
RoonOS 2.1 (build 271) production
RoonServer 2.70 (build 1671) production at the time of the incident
Wired Ethernet, static local network, no Wi-Fi involved
Local music storage: a ~1TB USB SSD (Micron/Crucial X8 family) attached directly to the ROCK, holding ~700GB of local files, separate from the ROCK’s internal boot/system storage
Streaming service: Qobuz
Timeline (2026-08-11, all times Pacific)
~9:35 AM — While actively playing a track, the Core’s own [stats] log line recorded a severe garbage-collection pause: 14385ms GC pause in last window (94.97% of window). Within the same second, all three of the Core’s RAAT client connections dropped simultaneously — two networked endpoints and its own loopback (127.0.0.1) connection, ruling out anything network-side as the cause. This produced a burst of [raat/tcpaudiosource] connect failed: Connection refusederrors.
Sometime after this, the Roon client apps began showing “Waiting for your Roon Server…” and eventually “There was an issue loading your library — restore a backup now.” The ROCK’s own web admin page (http://<host>/) showed Operating System: OK but Roon Database & Settings: Not Ready.
I rebooted the ROCK via its own admin page. The reboot completed normally (OS reported healthy, clean uptime reset).
After the reboot: RoonServer/Logs/ (the log directory itself) had been wiped entirely — no historical logs survived. RoonServer/Database/ was reduced to a bare Registry folder (no Core/library content beyond account/registry data). Library stats confirmed tracks: 0, albums: 0, artists: 0, playlists: 0 — a first-run-empty state, not a repaired one.
No usable Roon backup was found in the configured backup location.
Going through Roon’s own “Add Music”/initial setup flow again (from a second client, a MacBook), I later checked the attached USB SSD directly. It appeared as an empty folder over the ROCK’s own file share, then stopped appearing as a mount point at all.
I disconnected the drive and checked it independently on a Mac via Disk Utility, bypassing the ROCK entirely: the drive itself is completely healthy — mounts cleanly, valid ExFAT filesystem, no errors reported. But it shows only 14.8MB used out of ~1TB (999.95GB free). The ~700GB of music files are not on it. This rules out hardware failure or a bad cable — the drive was reformatted or otherwise had its content erased, not damaged.
I did not perform any deliberate “erase/format this drive” action. My best guess, not confirmed, is that this happened somewhere during the post-reset “Add Music”/storage setup flow, when Roon presumably no longer recognized the drive (since its own database record of it was gone) and may have offered to initialize it as new/internal storage — possibly with a confirmation step that wasn’t clear enough about the consequences, during a stressful multi-screen recovery process. I want to be upfront that I can’t pinpoint the exact action with certainty; I only confirmed the drive was already empty at the point I checked it, not the exact moment it became empty.
What I’ve ruled out
Network/switch issues: pings clean, no packet loss, no switch reboot logged, all local infrastructure confirmed healthy independently.
Drive hardware failure: the SSD mounts perfectly cleanly on a separate Mac with a valid filesystem — this is not a failed or dying drive.
User-initiated erase: I did not intentionally format or erase the music storage drive at any point.
Questions for Roon support
Is resetting to a fully empty library the designed recovery behavior when Database & Settingsshows Not Ready, rather than attempting repair or restore of the existing database? If so, is there a less destructive recovery path available that I should have used instead of a plain reboot?
Under what conditions does ROCK’s setup/storage flow format an attached drive automatically or with a confirmation step, when that drive was previously recognized library storage but is no longer in the (now-reset) database? Could this have happened without me consciously choosing “erase this drive”?
Is there any server-side/account-linked backup of my library metadata (play history, tags, playlists, edits) independent of what lived only in the ROCK’s own local database?
Given the severity here — a real risk of a paying customer’s entire local music library being silently erased during what looks like a routine recovery flow — is this a known issue, and is there a fix or a stronger safeguard planned?
Happy to provide full log excerpts, screenshots, or remote access if that helps investigate. I still have the reformatted SSD disconnected and untouched, in case it’s useful for you to look at directly or in case I attempt data recovery on it independently.
Thank you for your post and we’re sorry to hear this has happened to your setup. We’ll respond to your questions in point and proceed from there.
First off, for context: where had you pointed the configured Backup location, and do you still have access to that location? Latent database corruption or a sudden corruption event shouldn’t affect Backups.
To try to answer your report’s questions directly:
Resetting the database is not a recovery operation; it’s a factory reset. It won’t affect your library files, which are separate from the Roon database. It will erase your customizations and require you to reimport the files from your library after setting up a new database.
None. There is no condition under which the setup or storage flow formats an attached drive, and no confirmation-gated path that could have been clicked through by accident. RoonOS can write a filesystem in the web administration interface by using “Format,” but it only appears for a drive attached to the internal SATA connector. A USB-attached SSD never surfaces there. Reset all Settings / Databases makes no changes to storage at all.
No, this metadata and history is retained only in your database and in your Backups. It’s for this reason that we strongly recommend pointing Backups to a completely different drive that is not hosting the Roon database (or the Roon library).
Logs show the new Roon Server instance never enumerated the drive in question. A single clean single exFAT volume with 14.8MB used is what a desktop format tool produces (like Disk Utility).
What exactly did you see when the drive was first connected to the MacBook: any dialog, any error?
Was Disk Utility opened with that drive selected at any point, and was anything other than First Aid run?
Had that drive been connected to any other machine, Windows included, recently?
Was it ever formatted by the ROCK, or has it always been exFAT prepared elsewhere?
Good News: I installed a new M.2 SSD and reinstalled Rock with Qobuz so music is playing. I have an HDD with the music files so I can get back to normal
The backups were written to the Music Folder on the external SSD (bad idea). The SSD is in storage now
Yes, I am using Dropbox now
The fresh SSD was formatted on macOS and files copied there. I believe it has remained connected to Rock until failure.
Disk Utility showed no errors
Yes, just for status - no First Aid run
No, it went from Rock to macOS and now in storage
I believe that the inital formatting and music files copy was done by macOS
This is a screenshot from my mac soon after the incident. I only ran Disk Utility to get status
Your data is very likely still on that SSD. You reported 14.8 MB used out of 1 TB. That is the signature of a quick format, which rewrites the filesystem’s index but leaves the actual file data untouched on the drive. It is not the signature of a secure erase. So a large part of your 700 GB is probably still physically there, waiting to be recovered.
Two things matter if you want to try:
Do not write anything to that drive. No formatting, no copying files onto it, no letting an operating system “repair” it. You have it in storage already, which is exactly right.
Recover to a different drive, never back onto the same one. Tools people commonly use are PhotoRec, which is free, and R-Studio or Disk Drill, which are paid but easier. If the library matters to you, a professional recovery service is also a reasonable option and they will work from a copy of the drive rather than the original.
We cannot promise it will work, and file and folder names are often lost even when the audio itself is recovered. But given the numbers you reported, it is worth attempting before you write that drive off.
On what our logs can and cannot tell you. The diagnostics we hold begin after your rebuild, so they contain nothing from the moment of the incident itself. Those logs are gone and we cannot reconstruct them. What we can confirm from what we do hold is this: since the rebuild, no USB storage device has been attached to the ROCK at all, and the ROCK has not created a filesystem on anything. At the kernel level the only USB devices it has ever seen are its own internal hubs, a keyboard or mouse, and its Bluetooth module. That supports what Connor told you about the storage flow having no path to format a USB drive, but it does not tell us what happened on the morning of the 11th.
One thing worth naming plainly, because it is the part that turned a bad day into an unrecoverable one. Your backups were written to the Music folder on the same external SSD as your library. When that drive was emptied, the backups went with it. Had they been anywhere else, a single restore would have given you your playlists, edits, play history and tags back in minutes. Moving to Dropbox is the right response, and please also check under Settings, then Backups, that a schedule is running and that it reports a recent successful backup rather than just a configured location.
Glad you are playing music again. If you do attempt recovery and get the files back, tell us and we will help you get the library re-imported cleanly.
Wanted to follow up on this. Have you had a chance to try recovering the SSD to a different drive with a tool like PhotoRec, R-Studio, or Disk Drill, while keeping the original drive untouched and offline? Also, since the backups were on that same external SSD, could you check whether moving the backup location to Dropbox is now in place and that Settings > Backups shows a recent successful run, not just a configured destination? Let us know what you find or if you want to compare notes on the recovery side.
Please note, if we don’t hear back from you this thread may close automatically soon. If the thread auto-closes and you need further assistance, please submit a reopen support request via the technical support help form below and specify that the issue should be reopened. Thank you.
