Output of restic version

restic 0.18.0 compiled with go1.24.1 on netbsd/amd64

What backend/service did you use to store the repository?

rest-server

Problem description / Steps to reproduce

Every file on the filesystem that is being considered for backup throws an error like:
...
error: incomplete metadata for /dev/rwd2l: xattr.list /dev/rwd2l: operation not supported 16:11:13 [1418/1891]
error: incomplete metadata for /dev/rwd2m: xattr.list /dev/rwd2m: operation not supported error: incomplete metadata for /dev/rwd2n: xattr.list /dev/rwd2n: operation not supported
error: incomplete metadata for /dev/rwd2o: xattr.list /dev/rwd2o: operation not supported error: incomplete metadata for /dev/rwd2p: xattr.list /dev/rwd2p: operation not supported
error: incomplete metadata for /dev/rwd3a: xattr.list /dev/rwd3a: operation not supported error: incomplete metadata for /dev/rwd3b: xattr.list /dev/rwd3b: operation not supported
...
error: incomplete metadata for /var/yp: xattr.list /var/yp: operation not supported
error: incomplete metadata for /var/yp/Makefile.main: xattr.list /var/yp/Makefile.main: operation not supported
error: incomplete metadata for /var/yp/Makefile.yp: xattr.list /var/yp/Makefile.yp: operation not supported
error: incomplete metadata for /var/yp/binding: xattr.list /var/yp/binding: operation not supported
error: incomplete metadata for /var/yp/nicknames: xattr.list /var/yp/nicknames: operation not supported
...
Basically if the file is on the filesystem, there is an error produced for it.
Version 0.17.3 worked just fine. Version 0.18.0 spews errors.
I don't think RESTIC_REPOSITORY and RESTIC_PASSWORD variable content are overly relevant here, as those worked fine with 0.17.3 and are consistent with what are used for similar backups with Linux hosts. The back-ends are running rest-server (I see the issue on multiple NetBSD boxes, with two different rest-server back-ends).

The filesystems on the NetBSD boxes looks like (just one example, the others are similar):
file system: /dev/rraid1a
format FFSv1
endian little-endian
magic 11954 time Wed Apr 2 16:14:15 2025
superblock location 8192 id [ 61b9319f 3dc140e ]
cylgrp dynamic inodes 4.4BSD sblock FFSv2 fslevel 4
nbfree 1167103 ndir 20214 nifree 4773057 nffree 72516
ncg 212 size 20000000 blocks 19687926
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
bpg 11793 fpg 94344 ipg 23296
minfree 5% optim time maxcontig 4 maxbpg 4096
symlinklen 60 contigsumsize 4
maxfilesize 0x000400400402ffff
nindir 4096 inopb 128
avgfilesize 16384 avgfpdir 64
sblkno 8 cblkno 16 iblkno 24 dblkno 1480
sbsize 2048 cgsize 16384
csaddr 1480 cssize 4096
cgrotor 0 fmod 0 ronly 0 clean 0x02
wapbl version 0x1 location 2 flags 0x0
wapbl loc0 40007808 loc1 76896 loc2 512 loc3 3
usrquota 0 grpquota 0
flags wapbl
fsmnt /
volname swuid 0

I'll note that it's using FFSv2, and not FFSv2ea which would actually support the extended attributes.
I'm able to repeat this on 4 different NetBSD 10.0 systems, all running non-FFSv2ea filesystems, and all of which backed up perfectly with 0.17.3.

On one of the systems the nighly backup seemed to completely fail when run in automated fashion. They do seem to succeed in the end, albeit with very very noisy output of one error per file encountered.

Backup line reproducer looks like:
restic backup --one-file-system /
Problem is 100% reproducible for me (with 2 different rest-server back-ends). One system didn't send its usual backup report, which was how the issue was discovered. Other systems did send a report, looking normal, until we ran backups by hand and found that the xattr errors were being spewed there too. Unknown why the one system didn't actually complete the backup -- perhaps the backup summary (which also then contained one very long error line per file, with about 1 million files) didn't make it through the email system?

Reverting to 0.17.3 has everthing working fine again.

Expected behavior

Not attempt to do xattr support on a filesystem that doesn't support xattrs?
(or, at least don't consider it an error to not have xattrs for a filesystem that doesn't support xatters??)

Actual behavior

See above. One error reported for every file on the filesystem.

Do you have any idea what may have caused this?

Enabling xattrs on NetBSD, but the code not actually checking to see if the filesystem actually supports xattrs? I havn't had a chance to dig into #5174 to see what changed. Again, things work flawlessly with 0.17.3, but fail with 0.18.0.

Did restic help you today? Did it make you happy in any way?

Did a 'restic restore' to recover 2GB of data for a user today. Used it to restore 9TB of data for a user last week. Have probably close to 0.5PB of restic backups (data in restic repos, not raw data) across about 320 repos/machines, and am a very satisfied user and restic advocate :)