[Borgbackup] ACLs not preserved

[ralph strebbing]

On Sat, Feb 26, 2022 at 4:22 AM Thorsten Schöning <tschoening at am-soft.de> wrote:
> You should debug further, RSYNC isn't any different than BORG
> instances with ssh-agent. In both cases two instances of some reading
> app with full access to the filesystem are executed on the
> to-be-backed-up client.
If you have any specific things I can try, I'm open to further testing
and debugging. Borg is a new system for me, but I'm fairly well versed
in my systems as a general statement.

> That is the difference with SSHFS, which is an additional layer with
> additional limitations like unstable INODES, missing ACLs etc. Readers
> using that layer don't have access to all data, compared to readers
> natively running on the client. But that shouldn't be used in your
> setup.
If possible, the SSH-Agent process is what I need to have working, as
our backups would be started from the remote backup server via cron.

> Where does the following backup source comes from, what are the mount
> options exactly? Should be some EXT4 file system at filesrv1. You
> should provide the mount options and some example output showing that
> ACLs are really available.
The backup source comes from our file server (filesrv1), running
Ubuntu 20.04 that exists as a Proxmox KVM, with 2 Virtual HDDs, one
for the OS, the other for data (/storage mount).
Both of those however are running simple ext4, which by default Ubuntu
mounts with ACL support, but here is the output of `mount`:
/dev/sdb1 on /storage type ext4 (rw,relatime)
Output of fstab:
/dev/sdb1 /storage ext4 defaults 0 0
Output of tune2fs -l /dev/sdb1:
http://haste.thegamingcorner.net/odymexyjil.apache
The above is proof that my system supports ACLs. Similar output is
given on the backup server, but the simple fact is: Just rsyncing the
data preserves the ACLs, only when using Borg to the remote server,
either via push or pull am I having the issue.

> > /storage/netfiles/testfolder
>
> Your problem reads to me like there's some hiding layer between BORG
> and the filesystem. While that might be SSHFS, it shouldn't be,
> because SSH-AGENT doesn't use that.
>
> What happens when you run your backups multiple times after another?
> Check the output for modified files, as if all of those are modified
> over and over again, that's another hint for some layer like SSHFS
> with unstable INODES between backups.
The files are marked as unmodified if they are as such when running
backups multiple times on different archives.