SOLVED Default owner of replicated datasets on PULL server

[CoolSport]

Hi everyone,

This might be a very silly question for the experts here but for the life of me I couldn't figure this out. I've already looked in the forums and I already read the manual but can't find any topics regarding this matter.

I have 2 Freenas servers ( both Dell T20 with 16GB ECC memory, 4 x 4TB WD Reds in RAIDZ1 configuration running Freenas 9.10-STABLE ). I'm trying to replicate a dataset from one of server to the other.

The question is, how can I set who will be the owner of the replicated dataset in the PULL server?
I've tried both root and also a dedicated user as the replication user but the owner of the replicated dataset in the PULL server is set to a different user!

In the PULL server, I have setup a user named backupUser. I already created a dataset named BackUpDataset which is owned by backupUser.
In the PUSH server, I set backupUser as the dedicated user. I see that the replication works and the files get copied from PUSH server to PULL server.
My problem is the owner of the replicated files in PULL server is not backupUser! I tried root as replication user in the PULL server (by unchecking the dedicated user in replication task in PUSH server) and the result is the same. It's not owned by root.

Any help would be greatly appreciated!

Thanks!!!

 

[nojohnny101]

I know this is not the answer you probably were expecting but to access data on my PULL server, I just clone a snapshot and then create a share. I then change the owner and group recursively on the cloned snapshot. This grants me access.

To prevent unauthorized access, I simply don't have any sharing protocols on normally. Once I have finished accessing the share on PULL, I delete the cloned snapshot and turn off the sharing service.

 

[CoolSport]

Thanks for your response nojohnny101!
So is this really meant to work this way by design?
You are right that I am indeed trying to share the replicated dataset on the PULL server and your workaround will work.

I would like to understand though how the owner and permission is set on the replicated dataset.
There must be a setting on who will be the default owner of the replicated dataset in the PULL server. I don't get it why the dedicated user (or even root!) is not the default owner of the replicated dataset.

 

[CoolSport]

As a note, I know that the replicated dataset is meant to be READONLY and I have no issues with it being readonly ( and believe it should be for data security).
My question is more on how the user of the replicated dataset is decided... why is the dedicated replication user (or root) is not the default owner. It's would be hard to believe the owner is chosen arbitrarily..
Thanks again!

 

[depasseg]

I would like to understand though how the owner and permission is set on the replicated dataset.
There must be a setting on who will be the default owner of the replicated dataset in the PULL server. I don't get it why the dedicated user (or even root!) is not the default owner of the replicated dataset.

The replicated dataset is exactly that, a replica. So whoever the owner is on Push is the owner on Pull. It makes sense when you think of it it from recovering from a data loss and you replicate the data back to the original server location, everything works as if nothing happened.

 

[CoolSport]

Thanks depasseg for your response!

Hmmm, I'm a bit lost on what you mean by whoever the owner is on Push is the owner on Pull. I checked the ownership in both PUSH and PULL servers (using ls -ltrh on the shell ) and they are different..
How can ownership be copied/transferred if the owner in PUSH server does not exist in PULL server?

I have not done any type of recovery using the replicated data back to the original server ( and I hope I don't have to IRL) but I would like to try it and see what happens :)

 

[depasseg]

How can ownership be copied/transferred if the owner in PUSH server does not exist in PULL server?

On mine, I see the same UID and GID numbers.
Don't think of it as transferring ownership, replication is making a copy at the block level. So the "user and group" might not align on the replication target, due to different mapping of UID/GID to an AD user and group. But if I replicate that data back to the primary system, the mapping will be correct.

From my AD connected primary server:

Code:

[root@freenas2] /mnt/backup-tank2/from-FN1# ls -ltrhn
total 149
drwxrwxr-x+  3 0	  0		 4B Dec 26  2014 home/
drwxrwxr-x+  3 11178  10519	 4B Jan 11  2015 test2-home/
drwxr-xr-x   3 0	  0		 3B May  5  2015 time-machine/
drwxrwxr-x+  2 0	  10512	 4B Sep 25  2015 stuff/
drwxr-xr-x   4 0	  0		 4B Mar 28  2016 VM/
drwxr-xr-x   3 0	  0		 3B Mar 29  2016 home-unix/
drwxr-xr-x   7 98	 98		8B Apr  1  2016 backup/
drwxr-xr-x  14 0	  0		14B Apr  1  2016 ./
drwxr-xr-x   2 0	  0		 3B Apr  7  2016 RESERVED/
drwxr-xr-x   6 0	  0		 6B Jun 12 17:15 ../
drwxr-xr-x  35 0	  0		35B Aug 18 21:07 jails/
drwxrwxr-x+ 22 816	10513	40B Sep 13 16:44 media/
drwxr-xr-x   3 0	  0		 7B Oct 12 10:53 test99/
drwxr-xr-x   2 0	  0		 4B Oct 28 12:02 test992/
[root@freenas2] /mnt/backup-tank2/from-FN1# 

From my replication target:

Code:

[root@freenas1] /mnt/tank# ls -ltrhn
total 194
drwxrwxr-x+  3 0	  0		 4B Dec 26  2014 home/
drwxrwxr-x+  3 11178  10519	 4B Jan 11  2015 test2-home/
drwxr-xr-x   3 0	  0		 3B May  5  2015 time-machine/
drwxrwxr-x+  2 0	  10512	 4B Sep 25  2015 stuff/
drwxr-xr-x   4 0	  0		 4B Mar 28  2016 VM/
drwxr-xr-x   3 0	  0		 3B Mar 29  2016 home-unix/
drwxr-xr-x   7 98	 98		8B Apr  1  2016 backup/
drwxr-xr-x  14 0	  0		14B Apr  1  2016 ./
drwxr-xr-x   2 0	  0		 3B Apr  7  2016 RESERVED/
drwxr-xr-x  35 0	  0		35B Aug 18 21:07 jails/
drwxrwxr-x+ 22 816	10513	40B Sep 13 16:44 media/
drwxr-xr-x   3 0	  0		 7B Oct 12 10:53 test99/
drwxr-xr-x   2 0	  0		 4B Oct 28 12:02 test992/
drwxr-xr-x   4 0	  0	   120B Dec  5 21:09 ../
[root@freenas1] /mnt/tank# 

 

[CoolSport]

This is much clearer now!
What was throwing me off was that the user and group from PUSH server didn't match to the PULL server!
The UID/GID in PUSH server corresponds to the UID/GID of a different user in PULL server and that's what got me really confused!!!
Finally this makes a whole lot of sense to me now.

Thank you so much depasseg!!!