With the greatest of respect to the Roon support team here, ignore them
If you installed roon server on dietpi using the dietpi-installer, it will install it to permission level of root or dietpi depending on the user level you logged in as.
You need to mount the drive with the backup data using the same login as you did when you installed Roon server.
I install everything as root as I’m the only person with access to the server.
And yes, mount the drive to /mnt/dietpi_userdata/<name_of_the_drive>
@MusicD
Thank you for your replies. I have been through multiple iterations of ownership (root, dietpi) and permissions (754, 755, 777) across all files, as well as different locations and methods of restore. Unfortunately, the outcome has been the same in all cases.
I’ve confirmed from my point of view that the backup drive needs to be formatted to exFat.
I would reinstall DietPi to restore it to its correct permission levels.
Mount the back up drive via dietpi-drive_manager & copy its contents to another drive. Format the backup drive to exFat and mount again and name it e.g. Roon_Backups /mnt/dietpi_userdata/Roon_Backups
Copy back the backup files (depending on how many backups you had, this could take a while).
Via dietpi-software install Roon Server.
Open Roon remote/client and restore Roon from the backup. Locate the backup drive. Select the restore point.
Also to note, when Roon creates a backup folder it is named RoonBackups and you do not need to select that folder, just open the drive to its root folder and press on select.
Using dietpi-software to install Roon Server (or any of the choices listed) sandboxes the installation.
While Roon Server has user of roonserver it has no privileges by design.
There is no user called roonserver
You can of course create a user, but this isn’t how DietPi is meant to work. DietPi has user dietpi and root
So if a user gives /mnt/dietpi_userdata/<name_of_drive> permission to roonserver then it will have no privileges
Also to confirm, when mounting a drive to /mnt/dietpi_userdata/ you have to give the drive a name.
During the mounting process using dietpi-drive_manager you can set a drive to be the dietpi_userdata main user storage location. Convenient, but l would only use this option if I were to mount a NAS as local storage.
Thank you for the detailed responses - appreciated.
I don’t know that I’m in a position to reinstall my server to test Roon backups tbh
But, I can confirm a few things:
— multiple locations of said backup (it’s a single one: the last one I took before switching from Roon ROCK to DietPi) have been attempted, including off the original (exFAT-formatted) and mounted appropriately flash drive on which the original backup was taken.
— chmod 777 on all files throughout the backup tree
— chown as root:root, dietpi:dietpi, root:dietpi, you name it.
My music is stored on an internal sata ssd, legacy of the previous rock install and is not (going to be either) modified. It’s ext4 format.
I will be digging around some more on this when I get a moment.
To be clear: I do not have a running system with backups yet. I am merely attempting to restore into a new installation from my last backup with ROCK.
I have attempted to restore directly from the mounted flash drive (I mount outside of standard user data area for Dietpi in /mnt/rbackup and, as you probably are aware, exFAT does not support file-specific permissions, so commands such as chmod and chgrp are not available for use). Result: backup not found.
I cleaned up the hidden files with dot_clean and then copied the files (cp -pr as root) from the flash drive to a RoonBackups directory (owned by root:dietpi) under standard Dietpi user data location /mnt/dietpi_userdata. Chmod 775 on all files.
Result: backup not found.
Permissions:
/mnt/dietpi_userdata/RoonBackups# ls -la
total 16
drwxrwxr-x 3 root dietpi 4096 Nov 2 08:21 .
drwxrwxr-x 12 root dietpi 4096 Nov 21 01:05 ..
drwxrwxr-x 259 root dietpi 4096 Nov 2 08:21 3a9bf52d-4c2b-e82c-deb2-317c2ebc6141
-rwxrwxr-x 1 root dietpi 19 Nov 2 06:38 _roon_backup_root_
/mnt/dietpi_userdata/RoonBackups#
Sample in directory:
/mnt/dietpi_userdata/RoonBackups/3a9bf52d-4c2b-e82c-deb2-317c2ebc6141# ls -la
total 1044
drwxrwxr-x 259 root dietpi 4096 Nov 2 08:21 .
drwxrwxr-x 3 root dietpi 4096 Nov 2 08:21 ..
drwxrwxr-x 15 root dietpi 4096 Nov 2 08:21 00
drwxrwxr-x 14 root dietpi 4096 Nov 2 08:21 01
drwxrwxr-x 14 root dietpi 4096 Nov 2 08:21 02
drwxrwxr-x 11 root dietpi 4096 Nov 2 08:21 03
drwxrwxr-x 9 root dietpi 4096 Nov 2 08:21 04
drwxrwxr-x 7 root dietpi 4096 Nov 2 08:21 05
Parent dir:
/mnt/dietpi_userdata# ls -la
total 275620
drwxrwxr-x 12 root dietpi 4096 Nov 21 01:05 .
drwxr-xr-x 10 root root 4096 Nov 21 00:57 ..
drwxrwxr-x 2 dietpi dietpi 4096 Nov 2 15:26 Music
drwxrwxr-x 2 dietpi dietpi 4096 Nov 2 15:23 Pictures
drwxrwxr-x 3 root dietpi 4096 Nov 2 08:21 RoonBackups
drwxrwxr-x 2 dietpi dietpi 4096 Nov 2 15:23 Video
drwxrwxr-x 3 dietpi dietpi 4096 Nov 4 08:00 backup
drwx--x--- 12 root root 4096 Nov 21 00:58 docker-data
drwxrwxr-x 2 dietpi dietpi 4096 Nov 2 15:23 downloads
/mnt/dietpi_userdata#
Our QA team took a closer look at the backups you sent over, and it appears something may have gone wrong when the backup was originally created in ROCK.
Unfortunately, the zipped backup can’t be recognized on either a Linux (Ubuntu) or macOS machine. More specifically, the manifest file appears to be empty, which isn’t expected and prevents the backup from being processed.
We’ll be discussing this further with our senior development team, but at this point we’re unable to investigate the backups any further. I know this isn’t the answer you were hoping for, and we truly appreciate your patience while we work to understand what happened.
@mookr This is bad news.
Do you habe any older backup to restore from?
Or do you have the old ROCK installation still avaible to make a new backup (assuming you used a new SSD for the installation of DietPi anf put the old SSD with ROCK aside)?
Hoewever, you mentioned that you have the music files on the former internal storage drive of ROCK. This means you will most likely run into the same issues that i ran into when i moved from ROCK to DietPi as described in the forum thread linked above:
music files are not reassocited with the new storage location and treated as new
all edits to metadata, favourites, playback counts etc. of your old library database are lost
AFAIK, Roon never fixed this issue to date. At least there was no mentioning in the release notes of updates released since then and Roon also never came back to the above linked support thread once i posted i had found a solution by myself.
So even if you would manage to produce a valid backup of your old library database, it would be worthless for your new installation. My advice is to just start over and build a new library database.
Torben_Rick
(Torben - A Dane living in Hamburg - Roon Lifer)
35
I moved from ROCK to DietPi a year ago and had absolotly no problems with reinstalling the backup. I don’t know, if it is related to the fact, that I am only using “Backup Now” (manual backup)
@Torben_Rick
The problem is related only to the system default internal music storage which is treated differrently from other, manually added storage locations.
If you have your music files on an external storage location (USB drive connected to the RoonServer or NAS over the network) you‘re fine.
Torben_Rick
(Torben - A Dane living in Hamburg - Roon Lifer)
37
I don’t. I had a NUC10 with 2 internal drives - one for ROCK and one for music.
Now I have a NUC13 again with 2 internal drives but with DietPi (Roon Server, Samba etc.)
Funny, maybe the issue wasn’t present when you made the move from ROCK to DietPI last year and has been introduced in a later version of Roon after your migration? It was definitely present when I tried to migrate this year…
Thank you for those details. I was searching for a prior backup and I think I have found one, albeit several months old now. Unfortunately, I did not have a spare nvme so my ROCK install was wiped as part of the Dietpi install; I will not be able to re-do the backup.
I have not historically done a significant amount of metadata mods and am ok to redo those if required. I will see if other items you describe do occur. I’m hoping to not lose my playlists and listen later selection at a minimum and will keep an eye on favourites and counts.
At this point, “something” vs. nothing would be preferable.
I will not be able to fully test until this coming weekend. However, I can confirm that the restore from an old backup has worked i.e. one from several months ago. But, I have yet to look at the restore in detail.
