[Samba] R­e: R­e: D­­C2 d­enie­s ac­­cess­­ whe­­­n sa­­ving ­­t

?icro MEGAS micromegas at mail333.com
Sun Nov 2 07:46:35 MST 2014


> "Chan Min Wai" wrote:
> Basically what I'm think is like below. 
> 
> 1. Create minimal 2 GPO on each DC with different name. 
> 2. Copy the whole sysvol to sysvol2 including all ACL and xattr
> 3. Check their ACL to take reference. Including the directory. Using getfacl 
> 4. Run rsync and unison on sysvol2 and check the result of both sides. 
> 5. Both of the ACL should be same.
> 
> Hope to see where are the problem is. 

Well, I found out following. When I create a new GPO on DC2, the associated directory on the filesystem looks like that:

root at dc2:/var/lib/samba/sysvol/mydom.example.com/Policies/{927D76D9-0E8F-43E4-8393-2B39A24C0ADB}$ ls -lh
insgesamt 24K
-rwxrwx---+ 1 3000000 40000   66 Nov  2 15:25 GPT.INI
drwxrwx---+ 2 3000000 40000 4,0K Nov  2 15:25 Machine
drwxrwx---+ 2 3000000 40000 4,0K Nov  2 15:25 User

After I run rsync+unison command on DC1 the sync process seems to have deleted the two directories "Machine" and "User" on DC2 :( And yeah, the rsync+unison command showed following output...

$ /usr/bin/rsync -XAavz --log-file /var/log/samba/sysvol-sync.log --delete-after -f"+ */" -f"- *"  /var/lib/samba/sysvol root at dc2:/var/lib/samba  &&  /usr/bin/unison  &> /dev/null
building file list ... done
sysvol/mydom.example.com/Policies/
deleting sysvol/mydom.example.com/Policies/{5F5181D6-325D-4566-8B2E-0292E9F4995B}/User/
deleting sysvol/mydom.example.com/Policies/{5F5181D6-325D-4566-8B2E-0292E9F4995B}/Machine/
cannot delete non-empty directory: sysvol/mydom.example.com/Policies/{5F5181D6-325D-4566-8B2E-0292E9F4995B}

sent 7815 bytes  received 15 bytes  15660.00 bytes/sec
total size is 0  speedup is 0.00

Indeed, it deleted these two mentioned directories, it also tried to delete the directory 
{5F5181D6-325D-4566-8B2E-0292E9F4995B} but it wasn't able to do so.

After that mess, the directory on filesystem at DC2 looks like that:

root at dc2:/var/lib/samba/sysvol/mydom.example.com/Policies/{927D76D9-0E8F-43E4-8393-2B39A24C0ADB}$ ls -lh
insgesamt 8,0K
-rwxrwx---+ 1 3000000 40000 66 Nov  2 15:25 GPT.INI

So I'm pretty sure here is the problem. Because I have checked with "getfattr" the attributes, and they are correct on the particular files and directories. I guess it's no xattr issue. The culprit is rsync+unison command, which deleted these two directories on DC2, but _WHY_ ?

> "Rowland wrote"
> This is what I cannot really understand, why use the rsync command at 
> all, as it would seem that unison uses rsync itself to do the copying, 
> why not just run unison alone to do everything, there is probably a 
> reason for it, but it escapes me.

The wiki describes it, read https://wiki.samba.org/index.php/SysVol_Bidirectional_Replication#Setup_SysVol_on_DC2 It seems that rsync is creating the directory structure and unison copies the extended file attributes. I did check "man unison" and you're right, the command mentioned there is *confirmbigdel=false* . So I modified my /root/.unison/default.prf and changed it the line "confirmbigdeletes=false" to "confirmbigdel=false". But it didn't change anything on the problem explained above.

We need to fix the culprit made by rsync+unison command. any clues?

Mirco.


More information about the samba mailing list