Invalid extattr `user.security.selinux` on my system, cannot be deleted

openzfs / zfs

OpenZFS on Linux and FreeBSD

https://openzfs.github.io/openzfs-docs

Other

10.49k stars 1.74k forks source link

Invalid extattr `user.security.selinux` on my system, cannot be deleted #13823

Open Rudd-O opened 2 years ago

Rudd-O commented 2 years ago

[root@penny srv]# attr -l ./shared/Knowledge/Unsorted/Images/SlimSocial-47.jpg
Attribute "selinux" has a 35 byte value for ./shared/Knowledge/Unsorted/Images/SlimSocial-47.jpg
Attribute "DOSATTRIB" has a 32 byte value for ./shared/Knowledge/Unsorted/Images/SlimSocial-47.jpg
Attribute "security.selinux" has a -1 byte value for ./shared/Knowledge/Unsorted/Images/SlimSocial-47.jpg

These attributes are under namespace user.

That -1 byte attribute? Cannot be deleted:

[root@penny srv]# getfattr -d ./shared/Knowledge/Unsorted/Images/SlimSocial-47.jpg
# file: shared/Knowledge/Unsorted/Images/SlimSocial-47.jpg
user.DOSATTRIB=0sAAAEAAQAAABRAAAAIAAAAEqiU8JcMNcBSqJTwlww1wE=
./shared/Knowledge/Unsorted/Images/SlimSocial-47.jpg: user.security.selinux: Invalid argument

This is causing backup issues as per https://github.com/borgbackup/borg/issues/6988 .

Help!

Fedora 36, ZFS version deb1213098e2dc10e6eee5e5c57bb40584e096a6 (Fix memory allocation issue for BLAKE3 context).

ThomasWaldmann commented 2 years ago

A) The fact that you can not delete this in the fs is not a borgbackup bug.

B) You maybe could work around that bug though, using borg:

create a backup of the files
move away the files
restore the files

You'ld need the patched version of borg (https://github.com/borgbackup/borg/pull/6990) so you don't run into issues with these files.

C) The open question is still who or what creates/created these invalid xattrs.

Update: ehrm, sorry, didn't realise that I was writing in the openzfs issue tracker. :-) but i'll keep the info here, maybe it is useful.

Rudd-O commented 2 years ago

Correct. This is very vexing.

stale[bot] commented 1 year ago

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

ThomasWaldmann commented 1 year ago

No reason to close it by a bot before any zfs dev has even looked at it.

chenxiaolong commented 11 months ago

I ran into this with zfs 2.2.0. With zfs 2.2.0, setfattr -h -x user.security.selinux (and getfattr too) would fail with Invalid argument. Downgrading to zfs 2.1.13 allowed the xattrs to be deleted.

EDIT: Removed mention of Samba. I found this xattr on files that have never been exposed on a Samba share so that can't be the culprit.

NomadCF commented 7 months ago

We hadn't noticed this issue prior to upgrading. There really should be a pinned notice about it somewhere.

ThomasWaldmann commented 7 months ago

@NomadCF "The open question is still who or what creates/created these invalid xattrs."

Do you know?

NomadCF commented 7 months ago

@NomadCF "The open question is still who or what creates/created these invalid xattrs."

Do you know?

In our case we know these existed, but weren't "invalid" until upgrading ZFS. Rolling back we don't see the issue, with the same files as they are currently. But when rolling forward again, these "invalids" reappear.

So for us they're files that originate on Windows and Linux servers better than copied to ZFS hosts (Linux). And then then finally again accessed these invalid entries are brought to everyone's attention.

ThomasWaldmann commented 7 months ago

@NomadCF So are you saying you don't know precisely who (users?) / what (a specific program?) adds these xattrs?