JimB66 0 Posted September 18, 2021 Share Posted September 18, 2021 This is a continuation of my thread in the Roku forum: I'll recap that thread here, but it's there for reference if needed. I have Emby running as a docker on my unRAID NAS. It is on an "Unassigned Device" which is a HDD outside of the array. I used "rsync" to copy all of my dockers, and videos, from an old 250GB HDD to a new 1 TB one. Everything works just as before, including "Continue Watching" videos. The one thing though that did change is that I can no longer delete videos from the video folder. All other functions seem to work just fine. I thought it was an issue with the Roku app, which is where I started. But it looks to be a permissions issue on the new HDD. The files all have "nobody:users" as the owner:group. I was directed to the File Permissions thread here: Tried to run the commands in the "Solution" post: setfacl -m user:emby:rxw /mnt/disks/appdisk/TempVideo and I get the following error: setfacl: Option -m: Invalid argument near character 6 Someone else in that thread had the same issue, and there didn't seem to be a resolution. I did some digging/Googling (I know some Linux basics, but there's a lot I don't know) and it seems that "emby" is not a user: root@SleeperService:~# id emby id: ‘emby’: no such user So @ebr suggested I ask over here since it's now a permissions issue and not a Roku app issue. (Thanks to @ebr, @Luke and @Happy2Play for their help in the original thread.) I don't know what the owner settings were before the migration and I don't recall having to do anything at the command line when I installed Emby (although it's been a few years). Not sure why the owners weren't preserved via "rsync" but now I just need help correcting this. And I had considered just deleting then reinstalling the Emby docker since I assume the permissions get set correctly at install, but am hoping there's a simpler resolution. But I'm prepared to do that if needed. Thanks! Link to comment Share on other sites More sharing options...
Q-Droid 666 Posted September 18, 2021 Share Posted September 18, 2021 You have to figure out which user is running your Emby server, in your case the UID given for the Docker container. That is the user which needs access to the media whether at the user level (UID) or group level (GID). Link to comment Share on other sites More sharing options...
JimB66 0 Posted September 18, 2021 Author Share Posted September 18, 2021 1 hour ago, Q-Droid said: You have to figure out which user is running your Emby server, in your case the UID given for the Docker container. That is the user which needs access to the media whether at the user level (UID) or group level (GID). Ahh, OK. Let me see if I've got this. Here's the UID for the Emby docker: So then checking it: root@SleeperService:~# id 2 uid=2(daemon) gid=2(daemon) groups=2(daemon),4(adm) With that info I can go back to the "setfacl" command I originally tried, but use "daemon" instead of the (failed) "emby"? Link to comment Share on other sites More sharing options...
Solution Q-Droid 666 Posted September 19, 2021 Solution Share Posted September 19, 2021 (edited) Yes, pretty much. You can verify before running setfacl by checking which user:group owns the emby server logs. However, the setfacl command you've posted is not recursive and will only modify permissions on the one directory specified. It seems that when you ran rsync the ownership and permissions weren't preserved. That has to be set as one of the rsync options. The last few posts of the Linux Permissions thread should have what you need to make the changes recursively. Edited September 19, 2021 by Q-Droid Link to comment Share on other sites More sharing options...
JimB66 0 Posted September 19, 2021 Author Share Posted September 19, 2021 Thanks. I'll give it a try and see what happens. Yeah, I only posted the one "setfacl" command, since I couldn't go further. I will refer back to that thread for the full process. And thanks for the info about rsync. I'll have a closer look, just try to understand what happened and what I missed. Link to comment Share on other sites More sharing options...
JimB66 0 Posted September 20, 2021 Author Share Posted September 20, 2021 Sorry for the delay - I've learned to not do unfamiliar computer tasks when tired. Followed your post in the Linux Permissions thread, running both recursive commands. That seems to have fixed the issue! I can now delete existing, and new, video files from the Roku app. Much appreciated! Link to comment Share on other sites More sharing options...
Luke 37200 Posted September 20, 2021 Share Posted September 20, 2021 Thanks for the feedback. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now