From owner-freebsd-questions@freebsd.org Fri May 22 15:21:14 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D8542CB52C for ; Fri, 22 May 2020 15:21:14 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (net-2-44-121-52.cust.vodafonedsl.it [2.44.121.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mailserver.netfence.it", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49T9Dn3bPnz4Qwk for ; Fri, 22 May 2020 15:21:12 +0000 (UTC) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.15.2/8.15.2) with ESMTPSA id 04MFL1EP077899 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 22 May 2020 17:21:03 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be alamar.ventu Subject: Re: FreeBSD as an Active Directory Domain Controller To: byrnejb@harte-lyne.ca Cc: freebsd-questions@freebsd.org References: <1d6dd578eadaf13def02280d06f37ffe.squirrel@webmail.harte-lyne.ca> From: Andrea Venturoli Message-ID: <99ac30a7-126d-c0dd-6fab-e8fe445927f0@netfence.it> Date: Fri, 22 May 2020 17:21:01 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1d6dd578eadaf13def02280d06f37ffe.squirrel@webmail.harte-lyne.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49T9Dn3bPnz4Qwk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 2.44.121.52 as permitted sender) smtp.mailfrom=ml@netfence.it X-Spamd-Result: default: False [-3.07 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:2.44.121.52]; NEURAL_HAM_LONG(-0.97)[-0.974]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.30)[-0.300]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:30722, ipnet:2.44.0.0/16, country:IT]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 15:21:14 -0000 On 2020-05-21 21:31, James B. Byrne wrote: > Samba-4.4 and later removed support for nt style acls, Could you elaborate on this or give a pointer? I looked into 4.4.0 release notes, but found no mention of this removal. From the Samba Wiki, a Samba AD DC requires "Windows ACLs" (as opposed to POSIX ACLs). What do you mean with "NT style ACLs"? > Fast forward to now. Samba410-4.10.15 on FreeBSD-12.1p5 and using ZFS now can > be provisioned as a DC so acls obviously must be working on ZFS, I created a > Samab410 instance, checked that it could provision, undid that work and > reinstalled samba and used samba-tool to join the existing domain. I then > attempted to replicate the sysvol using rsync. Just to be sure, you are now: _ connecting via SSH from the *new* DC to the old DC; _ copying from UFS to ZFS; _ from a jail to a jail. > rsync -XAavz --delete-after --rsh='ssh' [192.168.8.65]:/var/db/samba4/sysvol > /var/db/samba4 > receiving file list ... done > > rsync: set_acl: sys_acl_set_file(sysvol, ACL_TYPE_ACCESS): Invalid argument (22) > > rsync: set_acl: sys_acl_set_file(sysvol/brockley-2016.harte-lyne.ca, > ACL_TYPE_ACCESS): Invalid argument (22) > > rsync: set_acl: sys_acl_set_file(sysvol/brockley-2016.harte-lyne.ca/Policies, > ACL_TYPE_ACCESS): Invalid argument (22) Just a shot in the dark: you're not using the stock rsync package, do you? At least in the past, an ACL patch was needed to support ACLs and that option is not on by default. I'm not sure it's still the case, however; now the patch states: > This patch adds backward-compatibility support for the --acls option. > Since the main release has never had ACL support, the trunk doesn't > need this code. If you want to make rsync 3.0.x communicate with an > older (patched) release, use this. I don't find the above particularly clear... if someone with more insight could step in... In any case, possibly you'll need to recompile rsync with that patch enabled (on both sides?). Or maybe again, this is not true anymore. Failing that, could you choose a sample file and report what ACLs are on the source and what you get on the target? bye av.