[bug]: directories with sticky bit cannot be backed up to some filesystems (exfat) using rsync

[gStart9]

Prerequisites

• I have searched for existing issues that already report this problem.

Server Hardware

All

StartOS Version

0351

Client OS

Linux

Client OS Version

All

Browser

Firefox

Browser Version

122

Current Behavior

root@upright-plunder:/embassy-data/package-data/volumes/lightning-terminal/data/main# ls -al
total 0
drwxr-xr-x 1 root root 28 Feb 26 18:56 .
drwxr-xr-x 1 root root 26 Feb 26 18:56 ..
drwxr-xr-x 1 root root 16 Feb 26 18:56 .lit
drwxr-xr-t 1 root root 0 Feb 26 18:56 .lnd
drwxr-xr-x 1 root root 22 Feb 26 18:56 start9

^this .lnd directory has a sticky bit set because it's mounted inside Lit container from the LND container

Sticky bit. It was used to trigger process to "stick" in memory after it is finished, now this usage is obsolete. Currently its use is system dependent and it is mostly used to suppress deletion of the files that belong to other users in the folder where you have "write" access to.
http://www.zzee.com/solutions/linux-permissions.shtml#setuid

Technically this may be a StartOS bug, but I believe the preferred solution will be to exclude the .lnd directory from the LiT backup -- Lit should not backup externally mounted .lnd directory -- LND should. (This indeed fixed lit)

An alternative could be to mount the .lnd directory with different permissions initially, or instruct rsync to discard the sticky bit permissions on copy.

Expected Behavior

Backup should not fail

Steps to Reproduce

1. Insert a physical disk formatted exfat
2. Attempt to perform a backup with where Lit is involved
3. See failure in the details of the backup report

Anything else?

No response

[MattDHill]

solved by start-fs fuse module