Jump to content

File permission issue after migrating to new HDD


JimB66
Go to solution Solved by Q-Droid,

Recommended Posts

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

Q-Droid

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

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:

image.png.248ecaf076b67212528dc9da8bd48dbf.png

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

  • Solution
Q-Droid

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 by Q-Droid
Link to comment
Share on other sites

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

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...