I have been experiencing permission problems with Emby. I thought at one point it was because I had tried updating Emby from within its web-UI, and removing & reinstalling the rock-on seemed to fix it.
I did some more investigating today when it was playing up and found that Emby is running as the daemon user (UID 2, GID 2) even though in the rock-on setup I choose a UID of 1000 and GID of 1001, both valid. I tried removing and reinstalling the rock-on again, the issue persists. My other rock-ons correctly use the IDs assigned to them.
Thanks for reporting this, I can reproduce the same behavior. I actually also can reproduce this when running manually the docker run command that Rockstor creates, which seems to suggest it is something odd related to the emby image. I too did not have this problem in the past, so I would encourage you to ask the question on the Emby forums: https://emby.media/community/
I’ll have a better look at their forums when I get the chance, but don’t hesitate to ask, they’re usually quite fast in answering, it seems.
A short-term solution would be to relax your permission on your emby-related shares (found under Shares > Access control), but there will be obvious security concerns…
I’m sorry I’m not able to help you further on this one.
So I took way too long to investigate this more, sorry I took so long to reply. I did appreciate the information you provided.
Searching the emby forum didn’t turn up any similar issues. I finally fixed it yesterday, though there’s still a puzzling error in the logs.
The solution was not just removing the rock-on via the GUI, but utilising
/opt/rockstor/bin/delete-rockon embyserver
Although emby was updating to new versions if I removed and re-installed the rock-on, it wasn’t until I cleared it more thoroughly with delete-rockon that re-installing actually pulled in the changes to add rock-on “wizard”. Something must have been stale, meaning I wasn’t getting the properly updated docker image/instructions. Now the UID and GID match what I choose, and I get the option for additional GIDs that was never showing up before.
The error I am seeing still is:
ERROR [storageadmin.util:44] Exception: Duplicate container (embyserver) definition detected. It belongs to another Rock-on (EmbyServer). Uninstall one of them and try again.
Which is puzzling given I purged the embyserver container from the DB. Anyhow, it doesn’t seem to be causing issues so I will leave that one for now.
Thanks a lot for the follow-up and all the details… they actually give me a few ideas as to what could have happened so I’ll try to provide some information below.
Mmmm, something seems odd, indeed, as you said. Currently, Rockstor does not delete a docker image upon a rock-on uninstall in order to make a subsequent re-installation faster and avoid unnecessarily re-downloading the same image. We do trigger a docker pull command at install, however, so that we can take advantage of docker’s default behavior, i.e. pulling a new image only if a newer version exists. If you’re interested, you can get more detailed on the underlying code in the related wiki post, under the Building the docker command section. In your case, I would have believed it should have done so. A clue to explain that may reside in your following quote, however:
The fact that you did not see this new option means your system didn’t refresh its rock-ons definitions. This process is completed every time one clicks on the Update button in the top right corner of the Rock-ons webUI page (more details on this process in the wiki post as well, section “Rock-on definition fetching”). Would you remember whether or not you clicked this button after uninstalling the Emby rock-on?
Another clue to explain everything, however, hides between two more pieces of information you gave (thanks again!):
and
Everything starts to make sense after noting the letter case used. Indeed, it is important to note that the delete-rockon script is case-sensitive, meaning that using that command should have removed the rock-on named embyserver. Did this script return an error or a confirmation that Rock-On(embyserver) metadata in the db is deleted'? While embyserver is the name used by the underlying container, I do not recall the rock-on being named this way. It actually used to be named EmbyServer… curious.
Interestingly, in the same refresh of the Emby rock-on definition linked above (and repasted below), you will see that the rock-on name changed from EmbyServer to Emby server.
Note how the former corresponds to the name listed in your error message?
Altogether, it suggests that you still have the old version listed in your database, and this is why you are seeing this error message. It seems you encountered some sort of conflict (at some point) resulting in conflicting information in the database.
This also means that I am a little puzzled by how this happened and how you have the Emby rock-on installed besides this error message (does it still appear in your logs, or is it from quite some time ago?).
We should be able to clean it up, however, but as I don’t want to create more problems, maybe we should make sure of what the current status is. If you’re interested, you can verify a few things:
what is the name of the Emby rock-on displayed in Rockstor’s webUI? Exact letter casing would be needed.
what is the output of the following command?
docker ps -a | grep emby
Sorry if I got a little confusing in my notes above, but I hope this helps,
Thanks again for looking into the details of this. I am starting to get a better understanding of the docker/rock-on system.
I believe I’ve used the update button at times, although perhaps not while while the Emby rock-on was uninstalled, and I recall having errors during the update at least on one occasion. Perhaps some of the underlying jumble I’ve created blocked the updates from correctly finishing.
When writing my previous post I didn’t check the case sensitivity. Reviewing my bash history I originally tried embyserver but had to correct it to EmbyServer for the script to work correctly. At least, I think that’s how it went.
I have just removed and re-added the Emby rock-on again to make sure my answer is up to date. No errors nor messages of duplicates appeared in /opt/rockstor/var/log/rockstor.log so I think it might be cleared up. The docker ps command returns:
542a695892e0 emby/embyserver “/init” 4 minutes ago Up 4 minutes
embyserver
Is there anything else I should check or does this seem to be correctly resolved? This probably stemmed from my initial use of Emby and trying to get it updated properly (improperly in my case). I now know the best practice for updating so hopefully will keep things cleaner in future.
The next job is replacing a failing disk before the errors get too much for it :-/
Unfortunately, there isn’t really a one-size-fits-all type of answer on how to update a project running in a docker container (and thus rock-on, indirectly):
The “docker way” to update a container would be to pull a new image and then re-create the container, and this is what Rockstor does at every install; but of course, because it does so during the rock-on install, one needs to uninstall and then reinstall, which can be unnecessarily cumbersome at times.
Some images are designed to be updated when they start–this is the case of most (if not all) images provided by Linuxserver.io–which means that a simple toggle OFF/ON of the rock-on is enough to update.
Finally, some projects include some sort of “update” button in their webUI. While most of these do not work when ran inside a docker container (such as Emby last time I checked), others do.
As you can see, this can be seen as a case-by-case scenario but the “docker way” should be the closest to a “universal solution”. It is quite cumbersome, however, but there has been discussion in this forum and the Github repositories to provide a user-friendly way to do so from Rockstor’s webUI.
In the meantime, as it (mostly) is a case-by-case affair, maybe we could describe the appropriate update procedure in the “more information” section of each rock-on to better guide the user.
If you have any doubt, don’t hesitate to post your plan and ask for feedback on this forum. There is a lot of experience in this procedure in this forum so I’m sure you’ll get good feedback. I myself am thinking of replacing my drives in the not-so-distant future and am planning on doing just that.
In case it helps, a good starting point would be to look at Rockstor’s documentation: http://rockstor.com/docs/data_loss.html
