So I'm in the process of migrating from a Window Server install running StableBit Drive Pool over to UNRAID. 

 

Since my UNRAID server doesn't have enough space to move the data over in one shot, I am using the unassigned drives plugin to move data from the NTFS disks into the pool and then I'm formatting the disk and adding to the pool once it's clear.

 

I'm doing the data copy directly on the command line using rsync with the archive flag and I've noticed that the files in the "user" directory are being written as root/root but the top level shares are nobody/users.

 

Should the files actually be owned by nobody/users?  If so, I will need to configure rsync to write as such and I'll need to change ownership of the files before I write too many more. 

 

On another note, I am loving UNRAID and should have migrated over YEARS ago.  What an amazing product.

10 minutes ago, jjross said:

Should the files actually be owned by nobody/users? 

Yes 

Tools-New Permissions

3 hours ago, trurl said:

Tools-New Permissions

 

I saw that but wasn't sure it was for the version I am using.  I'll give it a shot. 

 

I installed the "Fix Common Problems" plugin, which has been great, and it says:

 

"Permission Fix Excluded On:
(Docker Appdata Folders and CA backup Destination is automatically excluded)"

 

Does that mean I don't have to worry about the permissions script running on those folder?  Because when I go to the script page it says:

 

"Note that this tool may negatively affect any docker containers if you allow your appdata share to be included."

Actually, it turns out that the owner is not important as long as it is not 'root'.  All Share access users are members of the     users      group.   So as long as the Share Access member is given permission in the SMB share settings        SHARES   >>>   <share-name>       Scroll down to these sections:

 

In this case, the Share Access users   (smbuser and user) will have full read-write privileges to the files and directories in this Share even though these resources are variously owned by nobody, smbuser and user!  I had tested and verified this fact.  That is because the permissions on these resources for files is    rw-rw-rw-   (666)  and for directories   drwxrwxrwx  (777)  and the group is users  for everything. 

 

The reason I am pointing this out is so that folks who happen to discover that the owner is not 'nobody' that they don't panic and think there is some major problem on their server.  You do have to make sure that Docker containers and VMs set the group to   users     and the permissions to 666 and 777.  (This is a fully common problem as many of them will use the more secure Linux permission setting of 644 and 755.  This will cause a problem!)  And if one has to do that they might was well set the owner to be 'nobody'.