On 18/06/2023 08:25, Anders ?stling via samba wrote:> I am not convinced that it's a Samba issue, but someone might be able
to
> answer anyway
>
> We replicate directories and files from a Windows 2019 server to two
> destinations, both are supposed to be used in case of a disaster, but are
> also used for some specific tasks. One of the replication targets is a
> physical Windows 2012 server and the other one an Ubuntu/Samba virtual
> machine. The Samba VM is configured as a member server. It has been used by
> a group of people for accessing (mostly) static files for years without any
> problems.
> Replication is done using Robocopy in mirroring mode which is supposed to
> only replicate changed or new files to the two target systems. Herein lies
> the problem. The selective mirroring works fine between Windows and
> Windows. When replicating towards the Samba machine, timestamps seem to be
> ignored since each run is a full replication. I *think* that this behaviour
> started after upgrading the Samba from 4.12 to 4.15 recently.
> When I look at the timestamps on Windows and Linux/Ext4, they look
> identical, down to the second.
>
> The command used is ROBOCOPY SOURCE TARGET /MIR /NDL /NFL /NP /COPYALL
>
> So, is there a Robocopy guru out there that can advise us?
>
> PS1. The smb.conf looks like this
>
> [global]
> netbios name = HP-SRV03
> bind interfaces only = yes
> interfaces = lo ens3
> realm = XAGAREN.SE
> server role = MEMBER SERVER
> security = ADS
> workgroup = HPLTS
> idmap_ldb:use rfc2307 = yes
> idmap config * : backend = tdb
> idmap config * : range = 10000-20000
> idmap config HPLTS : backend = rid
> idmap config HPLTS : range = 30000-40000
> dedicated keytab file = /etc/krb5.keytab
> kerberos method = secrets and keytab
> winbind refresh tickets = yes
> winbind offline logon = yes
> winbind enum users = yes
> winbind enum groups = yes
> winbind nested groups = yes
> winbind expand groups = yes
> winbind use default domain = yes
> os level = 20
> domain master = no
> local master = no
> preferred master = no
> map to guest = bad user
> host msdfs = no
> client min protocol = SMB2
> server min protocol = SMB2
> client max protocol = SMB3
> unix extensions = no
> reset on zero vc = yes
> hide unreadable = yes
> acl group control = yes
> acl map full control = yes
> map acl inherit = yes
> ea support = yes
> vfs objects = acl_xattr
> store dos attributes = yes
> dos filemode = yes
> dos filetimes = yes
> restrict anonymous = 2
> strict allocate = yes
> guest account = bock
> guest ok = yes
> load printers = no
> printing = bsd
> printcap name = /dev/null
> disable spoolss = yes
> log level = 1
>
> [<share names>]
> comment = "comment"
> path = /share2/<share name>
> read only = no
> guest ok = no
>
> PS2. An additional side effect of the recent Samba upgrade is that we had
> to disable the user.map functionality (root/Administrator mapping) since
> Samba does not like this anymore. The replication script on the Windows
> side runs as Administrator, and I have seen other postings that this is now
> disapproved by Samba. So removing the user.map functionality solved that.
>
Not a robocopy guru, so cannot help there and your smb.conf looks okay,
though there are a few lines that don't strictly need to be there,
mainly because they are defaults. What is perplexing me most is that you
think that Samba does not like the user.map any more, can you please
elaborate where you have seen this posted ?
Rowland