Permissions on recently added replicated datasets not right

[Johnny Fartpants]

I'm running FreeNAS-9.10-STABLE-201604181743 on two servers although I've also seen this issue on 9.3.1 recently too.

When replicating from one box to the other all is fine but if you create a new dataset on primary it replicates fine to secondary but when you inspect the permissions they are wrong so for a recent example a dataset with windows permissions on the primary had unix permissions on the secondary and root had been set as the owner on the secondary when another user was owner on the primary. Also any ACLs I'd created were shot. Both boxes have the same users with the same UIDs so I know its not that. If I reboot secondary box when it comes back everything looks great again so it appears the information is transferring fine but just getting confused when landing.

Like I said:

1. This only happens on datasets created after the initial replication has been setup
2. After a reboot of secondary box everything is fine
3. I'm running the latest version of 9.10 but have seen this issue on two 9.3.1 boxes also
4. I've only noticed this issue since datasets replicated were marked as readyonly which I think started in 9.3.1 about 6 months ago

 

[cyberjock]

Can you provide steps to reproduce this?

 

[Johnny Fartpants]

Yes sure.

1. Create your pool and datasets
2. Setup your snapshot schedule for your parent and tick recursive
3. Replicate to your second system
4. Make sure your owner and group user is setup on the datasets and that the same UID is used on the second system.
5. Add a new dataset on your primary setting your owner and group to your user of choice and then wait for it to replicate and check your second system and you'll notice when checking permissions via the web interface things don't look right.

 

[Johnny Fartpants]

Probably worth setting your dataset permissions to Windows too as it defaults to UNIX. On mine I add ACLs too which vanish so you could try that as well if you wish but it's not needed to create the issue.

 

[Soloam]

It seams that I'm having the same problem https://forums.freenas.org/index.php?threads/replication-failing-dataset-permission-messed.43970/

Did you find out anything?

Thank you

 

[Johnny Fartpants]

I haven't checked it very recently as I haven't created any new datatsets but I believe it to still be an issue. If your issue is exactly the same as mine then rebooting the replica host seems to solve the issue. Like I said it appears all the permissions are correct but just not translating properly and only after reboot does this sort itself out.

 

[Johnny Fartpants]

I haven't checked it very recently as I havent created any new datatbut I believe it to still be an issue. If you issue is exactly the same as mine then rebooting the replica host seems to solve the issue. Like I said it appears all the permissions are correct but just not translating properly and only after reboot does this sort itself out.

 

[Soloam]

In my case, the pull and push are both the same machine! And after reading your post I tried to reboot the system, no effect, the permissions are messed up!

Another thing is when I browse on the console to the folder! The. zfs folder does not exist!

 

[Johnny Fartpants]

Yeah I read your post. Sounds like a different issue.

 

[cyberjock]

I'm not sure why you think this is a problem. It's really not (unless you're having a problem I can't reproduce).

When creating a dataset, folder, etc. a UID is attached. Let's say on ServerA you have user Cyberjock with UID 1050 and Johnny with UID 1051. Let's also say you have ServerB with Johnny with UID 1050 and Cyberjock with UID 1051.

If you give Cyberjock owner permissions on ServerA, then replicate to ServerB, then check the permissions on ServerB the permissions will show that Johnny is now, magically, the owner. He is only because the UIDs aren't kept in-sync. To alleviate this issue you either manually track and manage the UIDs, or you use something like AD or LDAP to ensure that UIDs are the same on both systems at all times.

This sounds like more of a misunderstanding of how replication works and not a bug or anything. All that you're seeing is that UID 1050 translates to Cyberjock on ServerA, but translates to Johnny on ServerB.

Of course, you are saying that your Users and their IDs are the same, but I don't know what else the problem could be.

 

[anodos]

I'm not sure why you think this is a problem. It's really not (unless you're having a problem I can't reproduce).

When creating a dataset, folder, etc. a UID is attached. Let's say on ServerA you have user Cyberjock with UID 1050 and Johnny with UID 1051. Let's also say you have ServerB with Johnny with UID 1050 and Cyberjock with UID 1051.

If you give Cyberjock owner permissions on ServerA, then replicate to ServerB, then check the permissions on ServerB the permissions will show that Johnny is now, magically, the owner. He is only because the UIDs aren't kept in-sync. To alleviate this issue you either manually track and manage the UIDs, or you use something like AD or LDAP to ensure that UIDs are the same on both systems at all times.

This sounds like more of a misunderstanding of how replication works and not a bug or anything. All that you're seeing is that UID 1050 translates to Cyberjock on ServerA, but translates to Johnny on ServerB.

Of course, you are saying that your Users and their IDs are the same, but I don't know what else the problem could be.

Just being pedantic, but AD will only ensure that the UIDs of AD users are the same. Local user accounts can still end up with different UIDs.

 

[Johnny Fartpants]

I'm not sure why you think this is a problem. It's really not (unless you're having a problem I can't reproduce).

When creating a dataset, folder, etc. a UID is attached. Let's say on ServerA you have user Cyberjock with UID 1050 and Johnny with UID 1051. Let's also say you have ServerB with Johnny with UID 1050 and Cyberjock with UID 1051.

If you give Cyberjock owner permissions on ServerA, then replicate to ServerB, then check the permissions on ServerB the permissions will show that Johnny is now, magically, the owner. He is only because the UIDs aren't kept in-sync. To alleviate this issue you either manually track and manage the UIDs, or you use something like AD or LDAP to ensure that UIDs are the same on both systems at all times.

This sounds like more of a misunderstanding of how replication works and not a bug or anything. All that you're seeing is that UID 1050 translates to Cyberjock on ServerA, but translates to Johnny on ServerB.

Of course, you are saying that your Users and their IDs are the same, but I don't know what else the problem could be.

Fair point but the UID are the same and even if they weren't it wouldn't explain why a reboot on the target system fixes everything. I'll have a play again on the more recent versions and see if I get the same issues on different boxes.

 

[cyberjock]

Is it possible this is a browser caching issue? I just tried this again and I'm still not seeing the issue. But my browser keeps a cache in RAM (disk caching is disabled) so I never have to deal with issues with browser caching.