samba - Nov 2021 - permissions, and maybe a violation of the least surprise principle

On 11/8/21 11:14, Jeremy Allison wrote:
> On Mon, Nov 08, 2021 at 09:38:18AM -0600, Patrick Goetz via samba wrote:
>> I'm down to the last step of my current re-implementation of Samba,
>> namely getting the permissions to work right.
>>
>> Here is the share section (+ some general) from my smb.conf file:
>>
>>
>> ? winbind refresh tickets = Yes
>> ? vfs objects = acl_xattr
>>
>> [share]
>> ? comment = Share Directory
>> ? path = /data/share
>> ? guest ok = no
>> ? browseable = yes
>> ? writeable = yes
>> ? create mask = 0770
>> ? directory mask = 0770
>> ? # inherit permissions = yes
>> ? follow symlinks = yes
>>
>>
>>
>> Here are the filesystem permissions on the directory:
>>
>> root at data2:/data# ls -ld share
>> drwxrws---+ 3 root ea-staff 4096 Nov? 6 16:31 share
>>
>> root at data2:/data# getfacl share
>> # file: share
>> # owner: root
>> # group: ea-staff
>> # flags: -s-
>> user::rwx
>> group::rwx
>> other::---
>> default:user::rwx
>> default:group::rwx
>> default:group:ea-staff:rwx
>> default:mask::rwx
>> default:other::---
>>
>>
>> Notice that the setgid bit is set, with group = (security group)
ea-staff
>>
>> So, I login on a Windows machine as a member of the ea-staff group, 
>> and save a document to the share:
>>
>> root at data2:/data/share# ls -l top*
>> -rwxrwx---+ 1 dhales domain users 227 Nov? 8 09:12 
>> top-secret_document_only_staff_should_see.rtf
>>
>>
>> Notice that the setgid bit on the parent folder was ignored, and the 
>> primary group assignment to the file is Domain Users.? Worse, anyone 
>> in Domain Users has access to write this file, although I suppose the 
>> lack of other? "x" permission on the parent folder might
prevent access.
>>
>> I think I read that if you are using Windows ACLs, then the Windows 
>> ACLs are checked and honored first; however this seems like a 
>> violation of the least surprise principle, since I'm getting user 
>> rights? elevations (namely Domain Users read/write access) that I 
>> don't want.
>>
>> These Wiki pages talk about using POSIX and Windows ACLs respectively:
>>
>> ?https://wiki.samba.org/index.php/Setting_up_a_Share_Using_POSIX_ACLs
>> ?https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>>
>> but I can't figure out how to tell the system I would prefer to
base
>> ACLs on POSIX rather than Windows ACLs.
>>
>>
>> Now, for the "it gets worse" category.? There is an awful lot
of
>> misinformation about configuring a Home share, perhaps because the 
>> Windows people seem to see this as something you use for backup only. 
>> The Home folder Wiki page also suggests that you can use GPO drive 
>> mapping for this rather than setting it in the user's Profile.
Looking
>> online I see Windows admins stating that one should *not* use GPO file 
>> sharing to configure the home directory and that only the user's 
>> Profile tab should be used for this.? In any case, Folder Redirection 
>> does not appear to work unless you set up a home directory under
Profile.
>>
>> Otherwise, using /home for this purpose appears to work fine and means 
>> the user will have immediate access to all their files when they ssh 
>> into the linux fileserver.? However:
>>
>> [home]
>> ? comment = Home Directories
>> ? path = /data/home
>> ? guest ok = no
>> ? browseable = no
>> ? writeable = yes
>> ? create mask = 0700
>> ? directory mask = 0700
>> ? follow symlinks = yes
>>
>> root at data2:/data# ls -ld home
>> drwxr-xr-x+ 8 root root 4096 Nov? 6 08:27 home
>> root at data2:/data# getfacl home
>> # file: home
>> # owner: root
>> # group: root
>> user::rwx
>> group::r-x
>> group:domain\040admins:rwx??? #effective:r-x
>> mask::r-x
>> other::r-x
>>
>>
>> /home is a bind mount to /data/home
>>
>>
>> The same user logs in on a W10 client and saves a file to his 
>> Documents folder:
>>
>> root at data2:~# cd /home/dhales/Documents/
>> root at data2:/home/dhales/Documents# ls -l my*
>> -rwxrwx---+ 1 dhales domain users 222 Nov? 8 09:25 
>> my-super-secret-file.rtf
>>
>>
>> So looks like the create mask is being ignored as well?
>>
>> I spend a lot of time adjusting permissions for users.? Most of them 
>> can't figure out how to do this themselves, and letting a user
loose
>> in the Windows ACL zoo seems like a recipe for disaster anyway.
>>
>> Consequently I'd prefer to manage POSIX ACLs via the filesystem and
>> ssh and then have the Windows ACL's approximated from that. Is
there a
>> way to do this?
>>
>> It also seems to me that the filesystem permissions should *never* be 
>> bypassed under any circumstances.
>>
>> Final question if anyone in the know has read this far. By default the 
>> Windows ACLs are stored in a TDB database on the fileserver's
filesystem?
> 
> No, that's not true. The Windows ACLs are stored by default
> in EA's attached to the file.
> 
>> What happens to these permissions if I migrate the data (say, via 
>> rsync) to another server? Seems like all the Windows ACLs will be lost 
>> unless I transfer the relevant database as well.
> 
> So long as rsync transfers EA's then all will work.


That's kind of the question, I guess. For ext4 the xattrs are stored in 
a separate data block referenced from inodes via inode.i_file_acl*
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extended_Attributes

I suppose rsync could/would be smart enough to follow this pointer to 
the xattrs.

This got me interested, so I'm running some tests.  For starters, if you 
`scp -p` files from an XFS filesystem to ext4, POSIX ALC's are not 
preserved:


root at kraken:/EM/21sep30a# getfacl 20210930_YD04_68_004_0.0_14.08.45.eer
# file: 20210930_YD04_68_004_0.0_14.08.45.eer
# owner: jonesimages
# group: jonesimages
user::rwx
user:abril:r-x
user:jones:rwx
user:cryosparc_user:r-x
user:afb938:r-x
group::r-x
group:cns-joneslabusers:r-x
mask::rwx
other::---


root at kraken:/EM/21sep30a# scp -p  20210930_YD04_68_004_0.0_14.08.45.eer 
pgoetz at frog.my-domain.com:/home/pgoetz/temp

[pgoetz at frog temp]$ getfacl 20210930_YD04_68_004_0.0_14.08.45.eer
# file: 20210930_YD04_68_004_0.0_14.08.45.eer
# owner: pgoetz
# group: pgoetz
user::rwx
group::rwx
other::---


Looks like rsync'ing from XFS to ZFS doesn't preserve POSIX extended 
ACLs, either. Damn.  I need to find an ext4 system I'm using POSIX ACLs 
on; maybe ext4 performs better in this regard.

Has anyone tested to see if copying files from ext4 to ext4 preserves 
POSIX extended ACLs? Under some conditions (say same UID's on each system)?

If I have to restore a 1PB filesystem from backup and need to 
reconstruct all the ACLs by hand it's going to be a sad, sad day.  Week, 
I meant; possibly month. Actually infinite, since I'll probably quit and 
will open a bakery instead. Bread doesn't have ACLs.

>
>
> >> What happens to these permissions if I migrate the data (say, via
> >> rsync) to another server? Seems like all the Windows ACLs will be
lost
> >> unless I transfer the relevant database as well.
> >
> > So long as rsync transfers EA's then all will work.
>
>
>
> That's kind of the question, I guess. For ext4 the xattrs are stored in
> a separate data block referenced from inodes via inode.i_file_acl*
> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extended_Attributes
>
> I suppose rsync could/would be smart enough to follow this pointer to
> the xattrs.
>
>
Yes, rsync will copy/synchronize extended attributes and POSIX ACLs.
However, keep in mind that POSIX ACLs and EAs are different things, and so
copying over one does not necessarily mean the other is copied over - if
you've applied Windows-type permissions that are stored in xattrs, and you
successfully copy over files with the EAs intact, the underlying POSIX ACLs
will not be copied/updated unless you make sure that you specifically copy
those over. The linkage between the POSIX ACLs and the EAs is done
completely by Samba and not by any Linux-level linkage between the two.

> This got me interested, so I'm running some tests.  For starters, if
you
> `scp -p` files from an XFS filesystem to ext4, POSIX ALC's are not
> preserved:
>
>
> root at kraken:/EM/21sep30a# getfacl 20210930_YD04_68_004_0.0_14.08.45.eer
> # file: 20210930_YD04_68_004_0.0_14.08.45.eer
> # owner: jonesimages
> # group: jonesimages
> user::rwx
> user:abril:r-x
> user:jones:rwx
> user:cryosparc_user:r-x
> user:afb938:r-x
> group::r-x
> group:cns-joneslabusers:r-x
> mask::rwx
> other::---
>
>
> root at kraken:/EM/21sep30a# scp -p  20210930_YD04_68_004_0.0_14.08.45.eer
> pgoetz at frog.my-domain.com:/home/pgoetz/temp
>
> [pgoetz at frog temp]$ getfacl 20210930_YD04_68_004_0.0_14.08.45.eer
> # file: 20210930_YD04_68_004_0.0_14.08.45.eer
> # owner: pgoetz
> # group: pgoetz
> user::rwx
> group::rwx
> other::---
>
>
> Looks like rsync'ing from XFS to ZFS doesn't preserve POSIX
extended
> ACLs, either. Damn.  I need to find an ext4 system I'm using POSIX ACLs
> on; maybe ext4 performs better in this regard.
>
> Has anyone tested to see if copying files from ext4 to ext4 preserves
> POSIX extended ACLs? Under some conditions (say same UID's on each
system)?
>
>
What flags are you using with rsync? There's a flag specifically for ACLs
(-A), and one for xattrs (-X) so you have to make sure to specify those. I
generally have very good success with copying ACL across filesystems,
though I cannot say for sure that I've tried from XFS to ZFS, etc. My rsync
command generally looks like this:

rsync -aADXHv <source> <destination>

Also, one thing I've found with rsync regarding ID mapping is this:
* If the user account exists on the destination system, ownership will be
properly changed so that the username matches. So, if account "nick"
has ID
1001 on system A, and account "nick" has ID 2001 on system B, if I
rsync
from system A to B, the account "nick" will own all of the files on
System
B that the account owned on system A, regardless of the fact that the
numeric ID does not match.
* If the user account does not exist on system B, or files are owned by a
UID that has no user on system A, then the ownership will just be copied
over numerically. So, if account "nick" exists on system A with ID
1001,
and there is no account "nick" on system B, then the files will be
copied
over with owner 1001. Also, if files on system A have an owner ID of 1002
with no account, those will just be copied over with the same numeric ID to
system B.

> If I have to restore a 1PB filesystem from backup and need to
> reconstruct all the ACLs by hand it's going to be a sad, sad day. 
Week,
> I meant; possibly month. Actually infinite, since I'll probably quit
and
> will open a bakery instead. Bread doesn't have ACLs.
>
>
I like bread. With butter. I will visit your bakery.

-Nick

Am 09.11.2021 um 13:30 schrieb Patrick Goetz via samba:
>
>
> On 11/8/21 11:14, Jeremy Allison wrote:
>> On Mon, Nov 08, 2021 at 09:38:18AM -0600, Patrick Goetz via samba
wrote:
>>> I'm down to the last step of my current re-implementation of
Samba, namely getting the permissions to work right.
>>>
>>> Here is the share section (+ some general) from my smb.conf file:
>>>
>>>
>>> ? winbind refresh tickets = Yes
>>> ? vfs objects = acl_xattr
>>>
>>> [share]
>>> ? comment = Share Directory
>>> ? path = /data/share
>>> ? guest ok = no
>>> ? browseable = yes
>>> ? writeable = yes
>>> ? create mask = 0770
>>> ? directory mask = 0770
>>> ? # inherit permissions = yes
>>> ? follow symlinks = yes
>>>
>>>
>>>
>>> Here are the filesystem permissions on the directory:
>>>
>>> root at data2:/data# ls -ld share
>>> drwxrws---+ 3 root ea-staff 4096 Nov? 6 16:31 share
>>>
>>> root at data2:/data# getfacl share
>>> # file: share
>>> # owner: root
>>> # group: ea-staff
>>> # flags: -s-
>>> user::rwx
>>> group::rwx
>>> other::---
>>> default:user::rwx
>>> default:group::rwx
>>> default:group:ea-staff:rwx
>>> default:mask::rwx
>>> default:other::---
>>>
>>>
>>> Notice that the setgid bit is set, with group = (security group)
ea-staff
>>>
>>> So, I login on a Windows machine as a member of the ea-staff group,
and save a document to the share:
>>>
>>> root at data2:/data/share# ls -l top*
>>> -rwxrwx---+ 1 dhales domain users 227 Nov? 8 09:12
top-secret_document_only_staff_should_see.rtf
>>>
>>>
>>> Notice that the setgid bit on the parent folder was ignored, and
the primary group assignment to the file is Domain Users.? Worse, anyone in
Domain Users has access to write this file, although I
>>> suppose the lack of other? "x" permission on the parent
folder might prevent access.
>>>
>>> I think I read that if you are using Windows ACLs, then the Windows
ACLs are checked and honored first; however this seems like a violation of the
least surprise principle, since I'm getting user
>>> rights? elevations (namely Domain Users read/write access) that I
don't want.
>>>
>>> These Wiki pages talk about using POSIX and Windows ACLs
respectively:
>>>
>>>
?https://wiki.samba.org/index.php/Setting_up_a_Share_Using_POSIX_ACLs
>>>
?https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>>>
>>> but I can't figure out how to tell the system I would prefer to
base ACLs on POSIX rather than Windows ACLs.
>>>
>>>
>>> Now, for the "it gets worse" category.? There is an awful
lot of misinformation about configuring a Home share, perhaps because the
Windows people seem to see this as something you use for backup
>>> only. The Home folder Wiki page also suggests that you can use GPO
drive mapping for this rather than setting it in the user's Profile. Looking
online I see Windows admins stating that one should
>>> *not* use GPO file sharing to configure the home directory and that
only the user's Profile tab should be used for this.? In any case, Folder
Redirection does not appear to work unless you set up
>>> a home directory under Profile.
>>>
>>> Otherwise, using /home for this purpose appears to work fine and
means the user will have immediate access to all their files when they ssh into
the linux fileserver.? However:
>>>
>>> [home]
>>> ? comment = Home Directories
>>> ? path = /data/home
>>> ? guest ok = no
>>> ? browseable = no
>>> ? writeable = yes
>>> ? create mask = 0700
>>> ? directory mask = 0700
>>> ? follow symlinks = yes
>>>
>>> root at data2:/data# ls -ld home
>>> drwxr-xr-x+ 8 root root 4096 Nov? 6 08:27 home
>>> root at data2:/data# getfacl home
>>> # file: home
>>> # owner: root
>>> # group: root
>>> user::rwx
>>> group::r-x
>>> group:domain\040admins:rwx??? #effective:r-x
>>> mask::r-x
>>> other::r-x
>>>
>>>
>>> /home is a bind mount to /data/home
>>>
>>>
>>> The same user logs in on a W10 client and saves a file to his
Documents folder:
>>>
>>> root at data2:~# cd /home/dhales/Documents/
>>> root at data2:/home/dhales/Documents# ls -l my*
>>> -rwxrwx---+ 1 dhales domain users 222 Nov? 8 09:25
my-super-secret-file.rtf
>>>
>>>
>>> So looks like the create mask is being ignored as well?
>>>
>>> I spend a lot of time adjusting permissions for users.? Most of
them can't figure out how to do this themselves, and letting a user loose in
the Windows ACL zoo seems like a recipe for disaster
>>> anyway.
>>>
>>> Consequently I'd prefer to manage POSIX ACLs via the filesystem
and ssh and then have the Windows ACL's approximated from that. Is there a
way to do this?
>>>
>>> It also seems to me that the filesystem permissions should *never*
be bypassed under any circumstances.
>>>
>>> Final question if anyone in the know has read this far. By default
the Windows ACLs are stored in a TDB database on the fileserver's
filesystem?
>>
>> No, that's not true. The Windows ACLs are stored by default
>> in EA's attached to the file.
>>
>>> What happens to these permissions if I migrate the data (say, via
rsync) to another server? Seems like all the Windows ACLs will be lost unless I
transfer the relevant database as well.
>>
>> So long as rsync transfers EA's then all will work.
>
>
>
> That's kind of the question, I guess. For ext4 the xattrs are stored in
a separate data block referenced from inodes via inode.i_file_acl*
> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extended_Attributes
>
> I suppose rsync could/would be smart enough to follow this pointer to the
xattrs.
>
> This got me interested, so I'm running some tests.? For starters, if
you `scp -p` files from an XFS filesystem to ext4, POSIX ALC's are not
preserved:
>
>
> root at kraken:/EM/21sep30a# getfacl 20210930_YD04_68_004_0.0_14.08.45.eer
> # file: 20210930_YD04_68_004_0.0_14.08.45.eer
> # owner: jonesimages
> # group: jonesimages
> user::rwx
> user:abril:r-x
> user:jones:rwx
> user:cryosparc_user:r-x
> user:afb938:r-x
> group::r-x
> group:cns-joneslabusers:r-x
> mask::rwx
> other::---
>
>
> root at kraken:/EM/21sep30a# scp -p? 20210930_YD04_68_004_0.0_14.08.45.eer
pgoetz at frog.my-domain.com:/home/pgoetz/temp
>
> [pgoetz at frog temp]$ getfacl 20210930_YD04_68_004_0.0_14.08.45.eer
> # file: 20210930_YD04_68_004_0.0_14.08.45.eer
> # owner: pgoetz
> # group: pgoetz
> user::rwx
> group::rwx
> other::---
>
>
> Looks like rsync'ing from XFS to ZFS doesn't preserve POSIX
extended ACLs, either. Damn.? I need to find an ext4 system I'm using POSIX
ACLs on; maybe ext4 performs better in this regard.
>
> Has anyone tested to see if copying files from ext4 to ext4 preserves POSIX
extended ACLs? Under some conditions (say same UID's on each system)?
>
> If I have to restore a 1PB filesystem from backup and need to reconstruct
all the ACLs by hand it's going to be a sad, sad day.? Week, I meant;
possibly month. Actually infinite, since I'll probably
> quit and will open a bakery instead. Bread doesn't have ACLs.
>
For sysvol replication i use rsync with rsyncd (no ssh involved) on ext4 without
problems since a few years. Also works with zfs in the mix.
If you have already transfered the files you may use robocopy on a windows
client to mirror/update only the permissions.

https://techcommunity.microsoft.com/t5/storage-at-microsoft/robocopy-mir-switch-8211-mirroring-file-permissions/ba-p/423662

Am 09.11.2021 um 13:30 schrieb Patrick Goetz via samba:
>
> On 11/8/21 11:14, Jeremy Allison wrote:
>> On Mon, Nov 08, 2021 at 09:38:18AM -0600, Patrick Goetz via samba
wrote:
>>> I'm down to the last step of my current re-implementation of
Samba, namely getting the permissions to work right.
>>>
>>> Here is the share section (+ some general) from my smb.conf file:
>>>
>>>
>>> ? winbind refresh tickets = Yes
>>> ? vfs objects = acl_xattr
>>>
>>> [share]
>>> ? comment = Share Directory
>>> ? path = /data/share
>>> ? guest ok = no
>>> ? browseable = yes
>>> ? writeable = yes
>>> ? create mask = 0770
>>> ? directory mask = 0770
>>> ? # inherit permissions = yes
>>> ? follow symlinks = yes
>>>
>>>
>>>
>>> Here are the filesystem permissions on the directory:
>>>
>>> root at data2:/data# ls -ld share
>>> drwxrws---+ 3 root ea-staff 4096 Nov? 6 16:31 share
>>>
>>> root at data2:/data# getfacl share
>>> # file: share
>>> # owner: root
>>> # group: ea-staff
>>> # flags: -s-
>>> user::rwx
>>> group::rwx
>>> other::---
>>> default:user::rwx
>>> default:group::rwx
>>> default:group:ea-staff:rwx
>>> default:mask::rwx
>>> default:other::---
>>>
>>>
>>> Notice that the setgid bit is set, with group = (security group)
ea-staff
>>>
>>> So, I login on a Windows machine as a member of the ea-staff group,
and save a document to the share:
>>>
>>> root at data2:/data/share# ls -l top*
>>> -rwxrwx---+ 1 dhales domain users 227 Nov? 8 09:12
top-secret_document_only_staff_should_see.rtf
>>>
>>>
>>> Notice that the setgid bit on the parent folder was ignored, and
the primary group assignment to the file is Domain Users.? Worse, anyone in
Domain Users has access to write this file, although I
>>> suppose the lack of other? "x" permission on the parent
folder might prevent access.
>>>
>>> I think I read that if you are using Windows ACLs, then the Windows
ACLs are checked and honored first; however this seems like a violation of the
least surprise principle, since I'm getting user
>>> rights? elevations (namely Domain Users read/write access) that I
don't want.
>>>
>>> These Wiki pages talk about using POSIX and Windows ACLs
respectively:
>>>
>>>
?https://wiki.samba.org/index.php/Setting_up_a_Share_Using_POSIX_ACLs
>>>
?https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>>>
>>> but I can't figure out how to tell the system I would prefer to
base ACLs on POSIX rather than Windows ACLs.
>>>
>>>
>>> Now, for the "it gets worse" category.? There is an awful
lot of misinformation about configuring a Home share, perhaps because the
Windows people seem to see this as something you use for backup
>>> only. The Home folder Wiki page also suggests that you can use GPO
drive mapping for this rather than setting it in the user's Profile. Looking
online I see Windows admins stating that one should
>>> *not* use GPO file sharing to configure the home directory and that
only the user's Profile tab should be used for this.? In any case, Folder
Redirection does not appear to work unless you set up
>>> a home directory under Profile.
>>>
>>> Otherwise, using /home for this purpose appears to work fine and
means the user will have immediate access to all their files when they ssh into
the linux fileserver.? However:
>>>
>>> [home]
>>> ? comment = Home Directories
>>> ? path = /data/home
>>> ? guest ok = no
>>> ? browseable = no
>>> ? writeable = yes
>>> ? create mask = 0700
>>> ? directory mask = 0700
>>> ? follow symlinks = yes
>>>
>>> root at data2:/data# ls -ld home
>>> drwxr-xr-x+ 8 root root 4096 Nov? 6 08:27 home
>>> root at data2:/data# getfacl home
>>> # file: home
>>> # owner: root
>>> # group: root
>>> user::rwx
>>> group::r-x
>>> group:domain\040admins:rwx??? #effective:r-x
>>> mask::r-x
>>> other::r-x
>>>
>>>
>>> /home is a bind mount to /data/home
>>>
>>>
>>> The same user logs in on a W10 client and saves a file to his
Documents folder:
>>>
>>> root at data2:~# cd /home/dhales/Documents/
>>> root at data2:/home/dhales/Documents# ls -l my*
>>> -rwxrwx---+ 1 dhales domain users 222 Nov? 8 09:25
my-super-secret-file.rtf
>>>
>>>
>>> So looks like the create mask is being ignored as well?
>>>
>>> I spend a lot of time adjusting permissions for users.? Most of
them can't figure out how to do this themselves, and letting a user loose in
the Windows ACL zoo seems like a recipe for disaster
>>> anyway.
>>>
>>> Consequently I'd prefer to manage POSIX ACLs via the filesystem
and ssh and then have the Windows ACL's approximated from that. Is there a
way to do this?
>>>
>>> It also seems to me that the filesystem permissions should *never*
be bypassed under any circumstances.
>>>
>>> Final question if anyone in the know has read this far. By default
the Windows ACLs are stored in a TDB database on the fileserver's
filesystem?
>>
>> No, that's not true. The Windows ACLs are stored by default
>> in EA's attached to the file.
>>
>>> What happens to these permissions if I migrate the data (say, via
rsync) to another server? Seems like all the Windows ACLs will be lost unless I
transfer the relevant database as well.
>>
>> So long as rsync transfers EA's then all will work.
>
>
>
> That's kind of the question, I guess. For ext4 the xattrs are stored in
a separate data block referenced from inodes via inode.i_file_acl*
> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extended_Attributes
>
> I suppose rsync could/would be smart enough to follow this pointer to the
xattrs.
>
> This got me interested, so I'm running some tests.? For starters, if
you `scp -p` files from an XFS filesystem to ext4, POSIX ALC's are not
preserved:
>
>
> root at kraken:/EM/21sep30a# getfacl 20210930_YD04_68_004_0.0_14.08.45.eer
> # file: 20210930_YD04_68_004_0.0_14.08.45.eer
> # owner: jonesimages
> # group: jonesimages
> user::rwx
> user:abril:r-x
> user:jones:rwx
> user:cryosparc_user:r-x
> user:afb938:r-x
> group::r-x
> group:cns-joneslabusers:r-x
> mask::rwx
> other::---
>
>
> root at kraken:/EM/21sep30a# scp -p? 20210930_YD04_68_004_0.0_14.08.45.eer
pgoetz at frog.my-domain.com:/home/pgoetz/temp
>
> [pgoetz at frog temp]$ getfacl 20210930_YD04_68_004_0.0_14.08.45.eer
> # file: 20210930_YD04_68_004_0.0_14.08.45.eer
> # owner: pgoetz
> # group: pgoetz
> user::rwx
> group::rwx
> other::---
>
>
> Looks like rsync'ing from XFS to ZFS doesn't preserve POSIX
extended ACLs, either. Damn.? I need to find an ext4 system I'm using POSIX
ACLs on; maybe ext4 performs better in this regard.
>
> Has anyone tested to see if copying files from ext4 to ext4 preserves POSIX
extended ACLs? Under some conditions (say same UID's on each system)?
>
> If I have to restore a 1PB filesystem from backup and need to reconstruct
all the ACLs by hand it's going to be a sad, sad day.? Week, I meant;
possibly month. Actually infinite, since I'll probably
> quit and will open a bakery instead. Bread doesn't have ACLs.
>
For sysvol replication i use rsync with rsyncd (no scp involved) on ext4 without
problems since a few years. Also works with zfs in the mix.

If you have already transfered the files you may use robocopy on a windows
client to mirror/update only the permissions.
https://techcommunity.microsoft.com/t5/storage-at-microsoft/robocopy-mir-switch-8211-mirroring-file-permissions/ba-p/423662