From: Scott Haiden <scott.b.haiden@gmail.com>
To: scott.b.haiden@gmail.com
Cc: linux-nfs@vger.kernel.org
Subject: Re: [REGRESSION]: NFS 4.2 reports "Operation Not Supported" on getxattr calls
Date: Thu, 28 Aug 2025 20:59:20 -0700 [thread overview]
Message-ID: <09073fa7-770b-44c7-8d44-d6a886b2e88d@gmail.com> (raw)
In-Reply-To: <528e7a88-9c63-43d4-8c67-50a36ceda8a7@gmail.com>
That got mangled by my mail client, I'll try (one time) to redo it with
formatting intact, sorry for the mixup, hopefully this doesn't also get
mangled:
Hello,
Between version v6.16.1 and v6.16.2 on the stable tree, NFS client
started reporting operation not supported when I issue getxattr calls. I
simply see:
$ strace -e getxattr getfattr -n user.hash.sha512 'S01E01 - Kassa.mkv'
getxattr("S01E01 - Kassa.mkv", "user.hash.sha512", NULL, 0) = -1
EOPNOTSUPP (Operation not supported)
S01E01 - Kassa.mkv: user.hash.sha512: Operation not supported
+++ exited with 1 +++
Before this issue cropped up, it simply returned the xattr as expected.
I did a git bisect between those two changes on the stable tree, and
found that the backport of this change
(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b01f21cacde9f2878492cf318fee61bf4ccad323 )
onto the stable tree is what caused it to start happening. The 6.12
longterm repo is also affected.
I built mainline 6.17-rc3 and it was still facing the issue as of last
night, but if I patch a reverse diff of that change on then getxattr
calls work again.
Please let me know if there's more information I should provide, or if
I'm just doing something wrong.
Thanks,
--Scott
next prev parent reply other threads:[~2025-08-29 3:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 3:46 [REGRESSION]: NFS 4.2 reports "Operation Not Supported" on getxattr calls Scott Haiden
2025-08-29 3:59 ` Scott Haiden [this message]
2025-08-29 16:57 ` [PATCH 0/4] More server capability fixes Trond Myklebust
2025-08-29 16:57 ` [PATCH 1/4] NFSv4: Don't clear capabilities that won't be reset Trond Myklebust
2025-08-29 16:57 ` [PATCH 2/4] NFSv4: Clear the NFS_CAP_FS_LOCATIONS flag if it is not set Trond Myklebust
2025-08-29 16:57 ` [PATCH 3/4] NFSv4: Clear NFS_CAP_OPEN_XOR and NFS_CAP_DELEGTIME if not supported Trond Myklebust
2025-08-29 16:57 ` [PATCH 4/4] NFSv4: Clear the NFS_CAP_XATTR flag if not supported by the server Trond Myklebust
2025-08-29 19:21 ` [PATCH 0/4] More server capability fixes Scott Haiden
2025-09-09 3:35 ` Scott Haiden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09073fa7-770b-44c7-8d44-d6a886b2e88d@gmail.com \
--to=scott.b.haiden@gmail.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.