From: Tian Lan <tilan@janestreet.com>
To: linux-nfs@vger.kernel.org
Cc: Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>
Subject: nfs: opening a file with O_WRONLY|O_CREAT flags can result in permission denied error
Date: Mon, 6 Jul 2026 17:34:22 -0400 [thread overview]
Message-ID: <20260706213435.659381-1-tilan@janestreet.com> (raw)
Hello,
We recently noticed there is a behavior change w.r.t opening a file
with the O_WRONLY|O_CREAT flags over the NFSv3 protocol after upgrading
the kernel from 6.1 LTS to 6.12 LTS. From the packets capturing, it seems
like the kernel would now issue an additional CREATE rpc call to the
remote NFS server regardless if the target file pre-exists or not.
The CREATE rpc request could return an EACCES error if the client only has
the write permission to the pre-existing file but no write permission on
the directory containing the pre-existing file. This causes the openat
syscall to fail with permission denied error which is not expected.
After doing some code tracing, it seems like the new behavior was
introduced as part of 7c6c5249f061 ("NFS: add atomic_open for NFSv3 to
handle O_TRUNC correctly."). We would like to confirm if the current
behavior that we are observing with the 6.12 kernel is expected given
that the new behavior breaks existing user's application code. We
currently have a workaround by explicitly remove the O_CREAT flag when
opening a pre-existing file for write, but would still prefer not have
to apply this workaround when upgrading to the newer kernel.
Best,
Tian
next reply other threads:[~2026-07-06 21:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 21:34 Tian Lan [this message]
2026-07-06 23:17 ` nfs: opening a file with O_WRONLY|O_CREAT flags can result in permission denied error Trond Myklebust
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=20260706213435.659381-1-tilan@janestreet.com \
--to=tilan@janestreet.com \
--cc=anna@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@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.