[Samba] rsync alternative -- smbclient?

Jonathon Reinhart jonathon.reinhart at gmail.com
Sat Jul 13 17:59:51 UTC 2019

I, too have been looking into alternatives to the rsync-based sysvol
replication workaround, and really liked the idea of using the
existing Sysvol SMB share, rather than a secondary protocol (with its
own authentication, etc).

When I realized that Andrew Bartlett was a primary developer of both
Samba and Rsync, I was even more surprised that Rsync doesn't support
an smb:// URL.

csync [1] is an alternative file-sync tool, written in part by Andreas
Schneider, who is, interestingly, also a Samba developer. This tool
does support smb:// paths. However it is explicitly bi-directional,
and I managed to **completely delete my source Sysvol share** with it.
I recommend against trying to use this tool for Sysvol sync (for now

So then I started playing around with smbclient and thought about
writing my own tool, using libsmbclient. Also, rather than running the
script periodically and "polling" for changes, my thought was to
leverage the "notify" feature of SMB to detect when things change on
the source. I have been working on writing my tool in Python. The
problem is that pysmbc [2] doesn't expose the notify APIs. So I
started re-writing the libsmbclient bindings in Cython (which is way
easier than hand-coding a CPython extension). But then I ran across a
bug [3] in libsmbclient in 4.9.x that prevents the notify API from
working. Sigh.

The biggest problem, however, is the discontinuity in the way ACLs /
xattrs are handled -- libsmbclient appears to translate the ACLs in
the smbc_getxattr() API, and there's no way to "apply" those to the
Linux filesystem backing the Sysvol share. (I don't have my notes with
specifics in front of me, but I remember looking at the result of
smbc_getxattr() and thinking "okay, what syscall am I supposed to use
to apply these to /var/lib/samba/sysvol/ ?")

So at this point, it seems hopeless. Perhaps Andrew or Andreas,
knowing much more than I about SMB ACLs and xattrs, could offer some
advice? Is it really impossible to sync Sysvol using SMB? Maybe I
could connect to both a remote **and** local SMB share, and apply them
in that way?

Some additional thoughts about your script, Joachim:

Thanks for pointing out --machine-pass.

You may find this method easier for locating the PDC emulator:

    host -t SRV _ldap._tcp.pdc._msdcs.<domain>

I have been setting the [netlogon] and [sysvol] shares to "read only =
yes" for all "secondary" DCs (those w/o the PDC emulator role).  This
is to prevent someone from connecting to and making changes on a
non-PDC-emulator DC w/ the GPO editor.

Jonathon Reinhart

[1] https://www.csync.org/
[2] https://pypi.org/project/pysmbc/
[3] https://lists.samba.org/archive/samba/2019-July/224125.html

On Sat, Jul 13, 2019 at 12:49 PM Joachim Lindenberg via samba
<samba at lists.samba.org> wrote:
> As you may have noticed I am looking into containers… in order to minimize configuration I also started looking into options for sysvol replication. I am aware of the list at https://wiki.samba.org/index.php/SysVol_replication_(DFS-R) Ignoring the robocopy option, essentially all of them use rsync, w/o ssh, w/o some extras like unison, osync, or lsyncd as Sven suggested, plus optionally defining a kind of topology by peer-to-peer-associations uni- or bi-directional.
> My understanding is that rsync without ssh allows for MitM-attacks (see Jan´s answer at https://stackoverflow.com/questions/8815031/how-much-is-in-secure-to-use-rsync-in-daemon-mode-without-ssh) – and while I don´t care about someone reading my policies, I definitely don´t want someone to modify them in transit. Imho rsync with ssh however is more cumbersome to setup, in particular when considering a number of DCs that might join or leave later on. Therefore I am considering to use smbclient instead. Smblient can use Kerberos to authenticate against peers plus can copy files, albeit not very efficient compared to rsync.
> Experimenting around I came up with the following script, which essentially identifies the “primary domain controller” and copies sysvol from there - as is suggested on https://wiki.samba.org/index.php/Rsync_based_SysVol_replication_workaround
> --- begin ---
> #!/bin/bash
> # prerequisite: apt-get install smbclient ldb-tools
> realminfo=`cat /etc/samba/smb.conf | grep realm | tr -d "' " `
> domain=`echo $realminfo | sed -n -E 's/realm=(.*)/\1/p' | tr A-Z a-z`
> privatedir=`smbd -b | grep "PRIVATE_DIR" | sed -n -E 's/PRIVATE_DIR:(.*)/\1/p' | xargs`
> sysvol=`cd $privatedir/..;pwd`/sysvol
> pdc=`samba-tool fsmo show | grep PdcEmulation | sed -n -E 's/PdcEmulationMasterRole owner: CN=NTDS Settings,CN=([^,]*),.*/\1/p'`
> peer=`ldbsearch --cross-ncs -H $privatedir/sam.ldb "(samAccountName=$pdc$)" | grep dNSHostName | sed -n -E 's/dNSHostName: (.*)/\1/p'`
> echo $peer
> mkdir /tmp/samba || echo
> touch /tmp/samba/olddir
> smbclient --machine-pass -e --max-protocol SMB3 \\\\$peer\\sysvol -c "prompt; recurse; dir *" >/tmp/samba/newdir
> cmp /tmp/samba/newdir /tmp/samba/olddir
> if [ $? -ne 0 ];
> then
>     mkdir /tmp/samba/sysvol
>     cd /tmp/samba/sysvol
>     smbclient --machine-pass -e --max-protocol SMB3 \\\\$pdc\\sysvol -c "prompt; recurse; mget *"
>     mv $sysvol $sysvol.old
>     mv /tmp/samba/sysvol $sysvol.old/..
>     samba-tool ntacl sysvolreset
>     rm -r $sysvol.old
>     mv /tmp/samba/newdir /tmp/samba/olddir
> fi
> --- end ---
> Imho
> Good: zero extra configuration, only reusing Samba configuration that exists already. More secure than rsync without ssh.
> Caveats: unidirectional like the trivial rsync option. Less efficient - but one could identify changed files and just copy these. Doesn´t check whether running on "PDC" yet.
> Bad: smbclient obviously does not copy the ACLs properly. In fact windows explorer crashes when displaying Security… I resorted to just resetting them as a quick & dirty workaround, but wouldn´t it be better if smbclient had an option to also copy ACLs?
> Feedback welcome, I am sure some stuff can be done more elegantly then in this proof-of-concept, and I am probably also missing something..
> Thanks, Joachim
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

More information about the samba mailing list