Confirmed on no changes to the 880 build on this problem. Without Guest Access, Roon Core can’t see anything in my “Music” shared folder. Turn Guest Access on (I used R/O), now it’s importing the files again. Given the amount of files in front of it, I’ll check on it in the morning.
I’m running QuTS Hero 5.0.0.1856 on a TVS-h1688x.
I’ve the same configuration and I’m having the same issue. The problem is that this fix is only temporary, since when you reboot files are not read again and you have to force the library rescan by changing any of the existing users access rights (does not mind if it is the guest user or another one, in my case).
Not sure this has been said here before, but it’s well established that working around this bug involves changing the folder you store your music in to “Guess Access Read/Write” or “Read Only”. And if you reboot the machine, then Roon Core forgets the local files requiring you to rest the Guest Access privs. What I didn’t realize until now is that the privilege setting for Guest Access doesn’t really matter. Just changing it to something else is enough for Roon Core to rediscover the library.
For example, my QNAP TVS-h1688x (Quts Hero 5.0.0.1856) was originally set up as Guest Access Read Only on my music shared folder so Roon could see it. Then I had to reboot the machine and Roon Core forgot about the music share. But this time I changed the Guest Access privileges to “Deny” and lo and behold, Roon rediscovers the music shared folder. So it doesn’t matter what you change the Guest Access privs to, the point it that it has to be changed from something to something else…anything else. Weird.
I wonder if the problem persists on QuTS Hero users or also QTS users? I’m at QTS (TS-253D) and haven’t had problems since the last few beta versions. Even after reboot things have worked normally. I’ve left the guest access at Read only on Roon database folder and Media folder.
One thing I’ve learned is that the QuTS Hero release usually trails the latest QTS release by anywhere from 1-3 months. So it’s possible there are changes in the current QTS release that haven’t filtered down to QuTS Hero. But right now, I’m in the weird position where any change in the Guest Access privs restores the ability to see the music shared folder, (R/W, R/O and yes, even Deny).
I have to take my unit off line today for a memory upgrade and when I restore power to it, i’m sure I’ll have to change the Guest Access privs yet again.
No doubt you’ve all thought about this idea: if you need to reboot your QNAP, just stop Roon on the NAS first.
When you’ve rebooted, start Roon on the NAS,
This avoids having to reload your Local Folders.
Hadn’t thought of that. Thanks for the tip!
And it didn’t work after all. Still had to modify privs after a reboot, regardless of whether Roon was shutdown first.
What I did was
all the Local Files were still there.
Perhaps I just got lucky.
Well there’s no difference if you switch steps 3 and 4 except that Roon never gets a chance of beginning to purge the library before local files begin the disappear.
All this reminds me of the old Unix/Linux “touch” command where years ago sometimes we would have to use the touch command on certain commands or files in order to update their modified dates so that software would run properly. Changing the privs is basically doing the same thing…updating the modified dates which somehow gets past the bug in Roon Core. Might be interesting to try seeing if the touch command via SSL makes any difference on a shared folder holding the music library vs doing a Guest privs change.
@support. Yesterday i was on a tech support call with Plex about an issue with my QNAP NAS and since the engineer was responsible for putting together the Plex package for QNAP QTS and QuTS Hero, we both decided to look at how Roon was setup and see if there was anything obvious that might be accounting for the local folders not showing bug. Sadly, the idea that he had (activating the Multimedia console and importing the music folders) didn’t turn out to bear fruit, but we did find one minor bug that needs attention.
If you create a shared folder (I’m using QuTS Hero 5.0), Roon Core will see the shared folder in Settings->Storage. But if you delete a shared folder, Roon Core never updates itself for the deletion. it was suggested that the code is missing having inotify look for IN_DELETE and IN_DELETE_SELF for changes.
I’m including this bug here and not in a separate thread since it may lead to something interesting in the search for the bug regarding the folders disappearing problem.
Hi @noris,
Is there any news from Roon team about this issue? Roon running on QNAP server is still not working.
Thank you.
I went to a new NAS and now unfortunately suffering the same. Hopefully the team can finally find a permanent fix for this.
Has anyone ever played around with the access rights in the console of the QNAP? E.g. create a new share and login via ssh. Now change rights and ownership of this share with chown/chmod (guest.guest, 666/777 to give full access) and then test whether something has changed. But that’s more for someone who knows a bit about Linux.
@noris Can you outline the status quo and next steps as this is really something all QNAP users are eagerly awaiting.
Sorry but not all, just the ones with this issue.
My QNAP Roon Server so far worked without issues through the past changes.
Same here, I just updated my QNAP TS253BE to QTS 5 (latest) and everything updated perfectly fine without any problem.
Roon just starts and runs normally (even after reboot)
Local folders are loaded correctly (my guest access is still the default deny)
Myself and the developer who maintains Plex on QNAP actually tried to dig into this a couple of weeks ago and try a few things like this. Unfortunately, nothing worked. The only thing we do know is that this isn’t quite an “enable guest access” workaround. The workaround is to change guest access, in any way. So if you reboot and had quest access enabled previously on Roon folders, Roon will forget its local folders until you change guest access again and that change can even be “deny”.
Well I just setup a new NAS from scratch with the latest QTS. It’s unfortunately also happening here.
Hope they soon identify what is the root of this problem.
Guess they have far enough user & debug data collected over that long time span the problem pertains.
Not that it matters to you, but i’d be curious to see how many was affected by this initially, and how many that still have issues. And like BlackJack i have never seen a glitch through all of this, on my QNAP based Roon Server. (TS-470 Pro, QTS4.3.6.1831)