Just to add another incident, same story here. Running as LXC container under proxmox, ZFS backed storage mounted to container. Worked fine in 1.7.
I have exactly the same issue since upgrading to 1.8. I can browse the folder on the Linux server, I can open the files, but there are no paths for Roon to add or rescan (path removed). In the interface, and my only option is to add a network share.
Ubuntu 20.04 with all the latest updates.
Sorry for the trouble here, @Jonathon_Wiebe!
Would you kindly use the directions found here and send us over a set of logs using a shared Dropbox link? Thanks!
Did some testing and Iâve confirmed roon sees local paths in a VM (not container) backed by different filesystem. Looks like ZFS breaks roon 1.8 but worked on 1.7.
Story here is familiar to me⌠Logs are already submitted. Thought Iâd check the thread in the Roon Community
But for the sake of it: Roon also running in ZFS backed LXC container in ProxmoxâŚ
Any idea or ETA on a fix? I understand this is complex and this isnât the only bug, but this is rapidly decreasing the âwife acceptance factorâ for Roon, and my subscription is up for renewal.
Try exporting the ZFS fs as a samba share and network mount that in Roon. Works for me.
No backups though so a real solution is wanted.
Running Ubuntu 20.04.2 LTS with LVM for /
(root) volume and a ZFS pool for media etc. Roon continues to work fine with 1.8.
Is everyone else using root on ZFS? Are you running the latest feature set?
So, my root isnât on ZFS.
My root is on tmpfs (ram) and I bind-mount selected directories into root during early boot, which allows my system to be stateless with the exception of things I specifically opt-in to retaining state for. (e.g. /var/lib/roon
). This seems to have the same effect though, since tmpfs
doesnât have a /dev/sdxY
device name, Roon refuses to look into it just like it does with ZFS mountpoints.
My music library is on ZFS, on a separate drive, and is mounted to /srv/music
during early boot as well.
All of this to say: I donât think the problem here is exclusive to ZFS, but rather to people with any root partition that goes even slightly outside of the norm of /dev/sdxY
device mounted to /
.
Hi,
I donât mean to add to the back-and-forth here, but anywayâŚ
I am running Roon Server Linux (Ubuntu 20.04.2 LTS) with zfs. Itâs on an Intel NUC with a single SSD. My music library is on this system in my home directory. It was working great and after the upgrade to 1.8, continues to work great.
I performed the upgrade via the Windows app from another computer (running in WINE emulation) which immediately found the Roon Server and then suggested to me to upgrade it, which I did. That took all of 10 or 15 seconds, then it asked me to re-launch the server, which I did. It came right back showing that it was at rev. 1.8.
Issue was that the 1.8 server couldnât find my music library. The Roon app showed the proper path in Settings > Storage > FOLDERS, although the path was now red and not functioning. In Linux, the library was where it should be. After much experimenting, the winning combination was to delete /var/roon/ and /opt/RoonServer, install the Roon Server via http://download.roonlabs.com/builds/roonserver-installer-linuxx64.sh, then install and configure Samba. I had to use an smb password as the Roon GUI wouldnât accept a blank password. I didnât have or need Samba before the upgrade. I had used cifs-utils as per the prerequisites, but Samba is a robust and has a lengthy and solid track record. I donât mind!
I guess I did a full reinstall. No problem with that.
Thanks,
Nick Z
Exactly my setup. No folders visable in 1.8; worked nicely in 1.7.
Iâm using ZFS too with Ubuntu 20.04. But my files reside on a NAS and are mounted with NFS.
What irritates me since quite some time is this error message:
02/11 18:33:09 Debug: [broker/filebrowser/volumeattached] initial listing found drive mounted at /var/music
02/11 18:33:09 Debug: [broker/filebrowser/volumeattached] skipping /var/music because it is not a /dev/sd[0-9]* (mountline: 10.0.3.24:/share/CACHEDEV1_DATA/Multimedia/Music/ /var/music nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.3.24,mountvers=3,mountport=30000,mountproto=udp,local_lock=none,addr=10.0.3.24 0 0)
Why does Roon check if the filesystem is mounted on /dev/sd*, this is simply wrong. This is against all standards.
It seems Iâm also not able to add any smb shares⌠Iâm getting âUnexpected errorâ
Same here. Samba or cifs utils, unexpected error. Not an issue with username or password.
Are they combing the entire / looking for media?:
02/09 21:44:45 Debug: [broker/filebrowser/volumeattached] skipping /proc/diskstats because it is not a /dev/sd[0-9]* (mountline: lxcfs /proc/diskstats fuse.lxcfs
This is a really failure prone and incorrect detection for file paths. When running as root you could overwrite all sorts of protected paths that would never have media in them. Or trigger unexpected behavior. The insistence on running a media server as root is my entire reason for putting Roon in a container/VM in the first place. Does anyone know if this behavior matches 1.7? I donât have my install anymore to check.
Right, I think this is the most infuriating aspect of this whole thing. Weâve all had our setups broken by some non-feature whose very idea is so obviously broken.
Why would you ever bother checking this? Youâll never be able to correctly check for the plethora of different, valid, ways people mount their data partitions.
I canât get Samba working either, it seems like Roon just ignores the mount.cifs
thatâs in PATH and tries to look for it somewhere (where it isnât).
At least in 1.7 they did. I never had my core on an other OS then Linux, but there I wondered often why they try to search
- /proc
- /sys
- tmpfs
Just to ignore them because they are not /dev/sd*
Looks like they just searched everything which was shown with âmountâ.
What Linux do you use?