Permissions / user question...

Status
Not open for further replies.

hungarianhc

Patron
Joined
Mar 11, 2014
Messages
234
Hi there,

Perhaps you can help me here ... The end result I'm trying to fix is that when I move a movie from a temporary location into my media directory, I get an error afterwards:

mv: /target/filesystem/filename: set owner/group: Operation not permitted

All my googling tells me that that is pretty benign. Still, though, I'd like to understand / fix it. My understanding is that it tries to re-set the permissions after moving the file, and fails. Here's my workflow. I have a dataset called "Dropzone" which allows for full read / write guest access via CIFS. When I rip a movie, I stick it here, etc. Once I verify that the movie ripped properly, I'll move it into my media collection. For that, I SSH in with a user I created called "modifier" that has read/write access to my media collection, as well as read/write access to the "Dropzone."

Is the issue that my guest CIFS account doesn't have enough privs? Should I add this account to a different group or something so that it creates the file w/ the correct privs? Or is the issue that my modifier account that I'm moving the file with doesn't have the right privs?

In the end, the move still works... The file is dropped in the right place, etc, but I'd like to set things up with best practices and avoid the error, if possible. Thanks!
 

marcevan

Patron
Joined
Dec 15, 2013
Messages
432
This is why Sickbeard and Couchpotato work so well...
 

hungarianhc

Patron
Joined
Mar 11, 2014
Messages
234
Did you figure this out?
I THINK so! I apologize in advance for this long explanation, but I'm also writing it out for my own benefit, to make sure I actually do understand what is going on here.
So let's back up to datasets. We have different ZFS datasets that we can create, and each one of those datasets has a different set of permissions. For example, my "Dropzone" dataset has a default group of "wheel" while my "Media" dataset" has a default group of "media." My understanding is that files I create in a directory will be owned by the creator, but part of the group of the directory. Thus, if my "guest" account, which belongs to group "nobody" creates a file in the "Dropzone" dataset, that file will be owned by "guest" and in the "wheel" group. I created a sample file and dropped it into my "Dropzone" dataset over CIFS via the guest account. I checked the permissions of the file...

Code:
[modifier@Hanson-NAS] /mnt/Storage/DropZone% ls -ltr hello*
-rw-rw-rw-  1 guest     wheel  308 Oct 25 19:40 hello.rtf


Okay so looking at the permissions, i can see it's owned by "guest" but in the "wheel" group.

I found this interesting note here:
When you move a file within the same filesystem, mv detaches the file from its old location and attaches it to its old location; metadata such as permissions remains the same. When you move a file to a different filesystem, mv copies the file, attempts to replicate as much metadata as possible, and removes the original.

So now this makes sense. If we essentially consider each dataset to be a separate filesystem, then that means the mv command will have to work like the latter case, where it copies the file, attempts to replicate as much metadata, and removes the original. So if I SSH in with my "modifier" account and mv the file from the temporary location to the new one, mv will copy the file, try to maintain the metadata, and delete the old one. Great, but since the new dataset is part of a different group and a different owner is copying the file, it can't preserve the permissions. Because it can't preserve the permissions, the error is thrown, but the file is successfully copied.

Until someone corrects me, I believe I'm interpreting things correctly. My NAS is doing a bunch of transfers right now, but once those all finish, I'll go ahead and play with some settings to see what I need to change to get rid of that error. Now that I actually understand the error better, I may just not care, since it's not relevant at all for media files, but it's good to know what causes it.

This is why Sickbeard and Couchpotato work so well...
Sickbeard / Couchpotato wouldn't solve the problem of using account 2 to copy the file that account 1 created from dataset1 to dataset2. Both of those apps typically / always deal with pirated content. I rip my personal collection.
 
Status
Not open for further replies.
Top