NFS EACCES regression since 6.15.4

NFS EACCES regression since 6.15.4

[Alkis Georgopoulos]

Hi, up to the 6.15.2 mainline kernel, these commands correctly returned 
EROFS (Read-only file system):

/usr/lib/klibc/bin/nfsmount -o ro 192.168.67.1:/srv/ltsp /mnt
true <>/mnt/some-existing-file
bash: /mnt/some-existing-file: Read-only file system

Strace says the respective call and result is:
openat(AT_FDCWD, "/mnt/some-existing-file", O_RDWR|O_CREAT, 0666) = -1 
EROFS (Read-only file system)

Since 6.15.4 mainline kernel, they started incorrectly returning EACCES 
instead:

bash: /mnt/some-existing-file: Permission denied
openat(AT_FDCWD, "/mnt/some-existing-file", O_RDWR|O_CREAT, 0666) = -1 
EACCES (Permission denied)

This breaks for example the klibc losetup command, which in turn breaks 
e.g. netbooting in certain cases:

/usr/lib/klibc/bin/losetup -f /mnt/some-existing-file
Permission denied

Looking at https://kernel.ubuntu.com/mainline/v6.15.4/CHANGES, I wonder 
if it's related to this change:
nfs: clear SB_RDONLY before getting superblock

Thank you,
Alkis Georgopoulos

[PATCH 0/6] Fix up NFS client mount option regressions

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

The recent changes to suppress the 'ro' and 'rw' mount options when
mounting the same NFS filesystem with different settings are causing
confusion with users, and are an unnecessary restriction. They represent
a functionality regression.

The following patch set reverts the regressions, before applying a
different set of fixes to address the original problem, which was one of
the NFSv4 mount automounter code failing to propagate the correct mount
options.

Trond Myklebust (6):
  Revert "nfs: ignore SB_RDONLY when remounting nfs"
  Revert "nfs: clear SB_RDONLY before getting superblock"
  Revert "nfs: ignore SB_RDONLY when mounting nfs"
  NFS: Automounted filesystem should inherit ro,noexec,nodev,sync flags
  NFS: Fix inheritance of the block sizes when automounting
  NFS: Fix up the automount fs_context to use the correct cred

 fs/nfs/client.c           | 21 +++++++++++++++++----
 fs/nfs/internal.h         |  3 +--
 fs/nfs/namespace.c        | 16 +++++++++++++++-
 fs/nfs/nfs4client.c       | 18 ++++++++++++++----
 fs/nfs/super.c            | 33 +++------------------------------
 include/linux/nfs_fs_sb.h |  5 +++++
 6 files changed, 55 insertions(+), 41 deletions(-)

-- 
2.52.0

[PATCH 1/6] Revert "nfs: ignore SB_RDONLY when remounting nfs"

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

This reverts commit 80c4de6ab44c14e910117a02f2f8241ffc6ec54a.

Silently ignoring the "ro" and "rw" mount options causes user confusion,
and is a regression.

Reported-by: Alkis Georgopoulos<alkisg@gmail.com>
Cc: Li Lingfeng <lilingfeng3@huawei.com>
Fixes: 80c4de6ab44c ("nfs: ignore SB_RDONLY when remounting nfs")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/super.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 72dee6f3050e..527000f5d150 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1051,16 +1051,6 @@ int nfs_reconfigure(struct fs_context *fc)
 
 	sync_filesystem(sb);
 
-	/*
-	 * The SB_RDONLY flag has been removed from the superblock during
-	 * mounts to prevent interference between different filesystems.
-	 * Similarly, it is also necessary to ignore the SB_RDONLY flag
-	 * during reconfiguration; otherwise, it may also result in the
-	 * creation of redundant superblocks when mounting a directory with
-	 * different rw and ro flags multiple times.
-	 */
-	fc->sb_flags_mask &= ~SB_RDONLY;
-
 	/*
 	 * Userspace mount programs that send binary options generally send
 	 * them populated with default values. We have no way to know which
-- 
2.52.0

[PATCH 2/6] Revert "nfs: clear SB_RDONLY before getting superblock"

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

This reverts commit 8cd9b785943c57a136536250da80ba1eb6f8eb18.

Silently ignoring the "ro" and "rw" mount options causes user confusion,
and is a regression.

Reported-by: Alkis Georgopoulos<alkisg@gmail.com>
Cc: Li Lingfeng <lilingfeng3@huawei.com>
Fixes: 8cd9b785943c ("nfs: clear SB_RDONLY before getting superblock")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/super.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 527000f5d150..9b9464e70a7f 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1308,17 +1308,8 @@ int nfs_get_tree_common(struct fs_context *fc)
 	if (IS_ERR(server))
 		return PTR_ERR(server);
 
-	/*
-	 * When NFS_MOUNT_UNSHARED is not set, NFS forces the sharing of a
-	 * superblock among each filesystem that mounts sub-directories
-	 * belonging to a single exported root path.
-	 * To prevent interference between different filesystems, the
-	 * SB_RDONLY flag should be removed from the superblock.
-	 */
 	if (server->flags & NFS_MOUNT_UNSHARED)
 		compare_super = NULL;
-	else
-		fc->sb_flags &= ~SB_RDONLY;
 
 	/* -o noac implies -o sync */
 	if (server->flags & NFS_MOUNT_NOAC)
-- 
2.52.0

[PATCH 3/6] Revert "nfs: ignore SB_RDONLY when mounting nfs"

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

This reverts commit 52cb7f8f177878b4f22397b9c4d2c8f743766be3.

Silently ignoring the "ro" and "rw" mount options causes user confusion,
and is a regression.

Reported-by: Alkis Georgopoulos<alkisg@gmail.com>
Cc: Li Lingfeng <lilingfeng3@huawei.com>
Fixes: 52cb7f8f1778 ("nfs: ignore SB_RDONLY when mounting nfs")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index 2ecd38e1d17a..ffd382aa31ac 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -13,7 +13,7 @@
 #include <linux/nfslocalio.h>
 #include <linux/wait_bit.h>
 
-#define NFS_SB_MASK (SB_NOSUID|SB_NODEV|SB_NOEXEC|SB_SYNCHRONOUS)
+#define NFS_SB_MASK (SB_RDONLY|SB_NOSUID|SB_NODEV|SB_NOEXEC|SB_SYNCHRONOUS)
 
 extern const struct export_operations nfs_export_ops;
 
-- 
2.52.0

[PATCH 4/6] NFS: Automounted filesystem should inherit ro,noexec,nodev,sync flags

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

When a filesystem is being automounted, it needs to preserve the
user-set superblock mount options, such as the "ro" flag.

Reported-by: Li Lingfeng <lilingfeng3@huawei.com>
Link: https://lore.kernel.org/all/20240604112636.236517-3-lilingfeng@huaweicloud.com/
Fixes: f2aedb713c28 ("NFS: Add fs_context support.")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/namespace.c | 6 ++++++
 fs/nfs/super.c     | 4 ----
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
index 5a4d193da1a9..dca055676c4f 100644
--- a/fs/nfs/namespace.c
+++ b/fs/nfs/namespace.c
@@ -149,6 +149,7 @@ struct vfsmount *nfs_d_automount(struct path *path)
 	struct vfsmount *mnt = ERR_PTR(-ENOMEM);
 	struct nfs_server *server = NFS_SB(path->dentry->d_sb);
 	struct nfs_client *client = server->nfs_client;
+	unsigned long s_flags = path->dentry->d_sb->s_flags;
 	int timeout = READ_ONCE(nfs_mountpoint_expiry_timeout);
 	int ret;
 
@@ -174,6 +175,11 @@ struct vfsmount *nfs_d_automount(struct path *path)
 		fc->net_ns = get_net(client->cl_net);
 	}
 
+	/* Inherit the flags covered by NFS_SB_MASK */
+	fc->sb_flags_mask |= NFS_SB_MASK;
+	fc->sb_flags &= ~NFS_SB_MASK;
+	fc->sb_flags |= s_flags & NFS_SB_MASK;
+
 	/* for submounts we want the same server; referrals will reassign */
 	memcpy(&ctx->nfs_server._address, &client->cl_addr, client->cl_addrlen);
 	ctx->nfs_server.addrlen	= client->cl_addrlen;
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 9b9464e70a7f..66413133b43e 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1315,10 +1315,6 @@ int nfs_get_tree_common(struct fs_context *fc)
 	if (server->flags & NFS_MOUNT_NOAC)
 		fc->sb_flags |= SB_SYNCHRONOUS;
 
-	if (ctx->clone_data.sb)
-		if (ctx->clone_data.sb->s_flags & SB_SYNCHRONOUS)
-			fc->sb_flags |= SB_SYNCHRONOUS;
-
 	/* Get a superblock - note that we may end up sharing one that already exists */
 	fc->s_fs_info = server;
 	s = sget_fc(fc, compare_super, nfs_set_super);
-- 
2.52.0

[PATCH 5/6] NFS: Fix inheritance of the block sizes when automounting

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

Only inherit the block sizes that were actually specified as mount
parameters for the parent mount.

Fixes: 62a55d088cd8 ("NFS: Additional refactoring for fs_context conversion")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/client.c           | 21 +++++++++++++++++----
 fs/nfs/internal.h         |  1 -
 fs/nfs/namespace.c        |  5 ++++-
 fs/nfs/nfs4client.c       | 18 ++++++++++++++----
 fs/nfs/super.c            | 10 +++-------
 include/linux/nfs_fs_sb.h |  5 +++++
 6 files changed, 43 insertions(+), 17 deletions(-)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 54699299d5b1..2aaea9c98c2c 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -784,10 +784,18 @@ static int nfs_init_server(struct nfs_server *server,
 		server->fattr_valid = NFS_ATTR_FATTR_V4;
 	}
 
-	if (ctx->rsize)
+	if (ctx->bsize) {
+		server->bsize = ctx->bsize;
+		server->automount_inherit |= NFS_AUTOMOUNT_INHERIT_BSIZE;
+	}
+	if (ctx->rsize) {
 		server->rsize = nfs_io_size(ctx->rsize, clp->cl_proto);
-	if (ctx->wsize)
+		server->automount_inherit |= NFS_AUTOMOUNT_INHERIT_RSIZE;
+	}
+	if (ctx->wsize) {
 		server->wsize = nfs_io_size(ctx->wsize, clp->cl_proto);
+		server->automount_inherit |= NFS_AUTOMOUNT_INHERIT_WSIZE;
+	}
 
 	server->acregmin = ctx->acregmin * HZ;
 	server->acregmax = ctx->acregmax * HZ;
@@ -977,8 +985,13 @@ EXPORT_SYMBOL_GPL(nfs_probe_server);
 void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source)
 {
 	target->flags = source->flags;
-	target->rsize = source->rsize;
-	target->wsize = source->wsize;
+	target->automount_inherit = source->automount_inherit;
+	if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE)
+		target->bsize = source->bsize;
+	if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_RSIZE)
+		target->rsize = source->rsize;
+	if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_WSIZE)
+		target->wsize = source->wsize;
 	target->acregmin = source->acregmin;
 	target->acregmax = source->acregmax;
 	target->acdirmin = source->acdirmin;
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index ffd382aa31ac..2e596244799f 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -152,7 +152,6 @@ struct nfs_fs_context {
 		struct super_block	*sb;
 		struct dentry		*dentry;
 		struct nfs_fattr	*fattr;
-		unsigned int		inherited_bsize;
 	} clone_data;
 };
 
diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
index dca055676c4f..9e4d94f41fc6 100644
--- a/fs/nfs/namespace.c
+++ b/fs/nfs/namespace.c
@@ -190,6 +190,10 @@ struct vfsmount *nfs_d_automount(struct path *path)
 	ctx->nfs_mod		= client->cl_nfs_mod;
 	get_nfs_version(ctx->nfs_mod);
 
+	/* Inherit block sizes if they were specified as mount parameters */
+	if (server->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE)
+		ctx->bsize = server->bsize;
+
 	ret = client->rpc_ops->submount(fc, server);
 	if (ret < 0) {
 		mnt = ERR_PTR(ret);
@@ -289,7 +293,6 @@ int nfs_do_submount(struct fs_context *fc)
 		return -ENOMEM;
 
 	ctx->internal		= true;
-	ctx->clone_data.inherited_bsize = ctx->clone_data.sb->s_blocksize_bits;
 
 	p = nfs_devname(dentry, buffer, 4096);
 	if (IS_ERR(p)) {
diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 4e972f85d0ca..96bccefbe2cb 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -1179,10 +1179,20 @@ static int nfs4_init_server(struct nfs_server *server, struct fs_context *fc)
 	if (error < 0)
 		return error;
 
-	if (ctx->rsize)
-		server->rsize = nfs_io_size(ctx->rsize, server->nfs_client->cl_proto);
-	if (ctx->wsize)
-		server->wsize = nfs_io_size(ctx->wsize, server->nfs_client->cl_proto);
+	if (ctx->bsize) {
+		server->bsize = ctx->bsize;
+		server->automount_inherit |= NFS_AUTOMOUNT_INHERIT_BSIZE;
+	}
+	if (ctx->rsize) {
+		server->rsize =
+			nfs_io_size(ctx->rsize, server->nfs_client->cl_proto);
+		server->automount_inherit |= NFS_AUTOMOUNT_INHERIT_RSIZE;
+	}
+	if (ctx->wsize) {
+		server->wsize =
+			nfs_io_size(ctx->wsize, server->nfs_client->cl_proto);
+		server->automount_inherit |= NFS_AUTOMOUNT_INHERIT_WSIZE;
+	}
 
 	server->acregmin = ctx->acregmin * HZ;
 	server->acregmax = ctx->acregmax * HZ;
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 66413133b43e..57d372db03b9 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1091,8 +1091,9 @@ static void nfs_fill_super(struct super_block *sb, struct nfs_fs_context *ctx)
 	sb->s_blocksize = 0;
 	sb->s_xattr = server->nfs_client->cl_nfs_mod->xattr;
 	sb->s_op = server->nfs_client->cl_nfs_mod->sops;
-	if (ctx->bsize)
-		sb->s_blocksize = nfs_block_size(ctx->bsize, &sb->s_blocksize_bits);
+	if (server->bsize)
+		sb->s_blocksize =
+			nfs_block_size(server->bsize, &sb->s_blocksize_bits);
 
 	switch (server->nfs_client->rpc_ops->version) {
 	case 2:
@@ -1338,13 +1339,8 @@ int nfs_get_tree_common(struct fs_context *fc)
 	}
 
 	if (!s->s_root) {
-		unsigned bsize = ctx->clone_data.inherited_bsize;
 		/* initial superblock/root creation */
 		nfs_fill_super(s, ctx);
-		if (bsize) {
-			s->s_blocksize_bits = bsize;
-			s->s_blocksize = 1U << bsize;
-		}
 		error = nfs_get_cache_cookie(s, ctx);
 		if (error < 0)
 			goto error_splat_super;
diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
index 4ba04de6b1ca..c58b870f31ee 100644
--- a/include/linux/nfs_fs_sb.h
+++ b/include/linux/nfs_fs_sb.h
@@ -172,6 +172,11 @@ struct nfs_server {
 #define NFS_MOUNT_FORCE_RDIRPLUS	0x20000000
 #define NFS_MOUNT_NETUNREACH_FATAL	0x40000000
 
+	unsigned int		automount_inherit; /* Properties inherited by automount */
+#define NFS_AUTOMOUNT_INHERIT_BSIZE	0x0001
+#define NFS_AUTOMOUNT_INHERIT_RSIZE	0x0002
+#define NFS_AUTOMOUNT_INHERIT_WSIZE	0x0004
+
 	unsigned int		caps;		/* server capabilities */
 	__u64			fattr_valid;	/* Valid attributes */
 	unsigned int		rsize;		/* read size */
-- 
2.52.0

[PATCH 6/6] NFS: Fix up the automount fs_context to use the correct cred

[Trond Myklebust]

From: Trond Myklebust <trond.myklebust@hammerspace.com>

When automounting, the fs_context should be fixed up to use the cred
from the parent filesystem, since the operation is just extending the
namespace. Authorisation to enter that namespace will already have been
provided by the preceding lookup.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
---
 fs/nfs/namespace.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
index 9e4d94f41fc6..af9be0c5f516 100644
--- a/fs/nfs/namespace.c
+++ b/fs/nfs/namespace.c
@@ -170,6 +170,11 @@ struct vfsmount *nfs_d_automount(struct path *path)
 	if (!ctx->clone_data.fattr)
 		goto out_fc;
 
+	if (fc->cred != server->cred) {
+		put_cred(fc->cred);
+		fc->cred = get_cred(server->cred);
+	}
+
 	if (fc->net_ns != client->cl_net) {
 		put_net(fc->net_ns);
 		fc->net_ns = get_net(client->cl_net);
-- 
2.52.0

Re: [PATCH 0/6] Fix up NFS client mount option regressions

[Li Lingfeng]

Hi Trond,

在 2025/11/29 12:06, Trond Myklebust 写道:
> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>
> The recent changes to suppress the 'ro' and 'rw' mount options when
> mounting the same NFS filesystem with different settings are causing
> confusion with users, and are an unnecessary restriction. They represent
> a functionality regression.
>
> The following patch set reverts the regressions, before applying a
> different set of fixes to address the original problem, which was one of
> the NFSv4 mount automounter code failing to propagate the correct mount
> options.
>
> Trond Myklebust (6):
>    Revert "nfs: ignore SB_RDONLY when remounting nfs"
>    Revert "nfs: clear SB_RDONLY before getting superblock"
>    Revert "nfs: ignore SB_RDONLY when mounting nfs"
>    NFS: Automounted filesystem should inherit ro,noexec,nodev,sync flags
>    NFS: Fix inheritance of the block sizes when automounting
>    NFS: Fix up the automount fs_context to use the correct cred
>
>   fs/nfs/client.c           | 21 +++++++++++++++++----
>   fs/nfs/internal.h         |  3 +--
>   fs/nfs/namespace.c        | 16 +++++++++++++++-
>   fs/nfs/nfs4client.c       | 18 ++++++++++++++----
>   fs/nfs/super.c            | 33 +++------------------------------
>   include/linux/nfs_fs_sb.h |  5 +++++
>   6 files changed, 55 insertions(+), 41 deletions(-)
After this series of patches was merged, I found that the issue described
in link [1] has appeared again.

[root@nfs-client1 ~]# mount /dev/sda /mnt2
[root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)" >/etc/exports
[root@nfs-client1 ~]# systemctl restart nfs-server
[root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
[root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
[root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
[root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
[root@nfs-client1 ~]# mount | grep nfs4
127.0.0.1:/ on /mnt/sdaa type nfs4 
(ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)
127.0.0.1:/ on /mnt/sdaa type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)
127.0.0.1:/ on /mnt/sdaa type nfs4 
(ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)
127.0.0.1:/ on /mnt/sdaa type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)
[root@nfs-client1 ~]# uname -a
Linux nfs-client1 6.19.0-rc7+ #178 SMP PREEMPT_DYNAMIC Thu Jan 29 
14:06:54 CST 2026 x86_64 x86_64 x86_64 GNU/Linux
[root@nfs-client1 ~]#

[1] 
https://lore.kernel.org/all/20241114045303.1656426-1-lilingfeng3@huawei.com/

Thanks,
Lingfeng.

Re: [PATCH 0/6] Fix up NFS client mount option regressions

[Trond Myklebust]

On Thu, 2026-01-29 at 15:06 +0800, Li Lingfeng wrote:
> Hi Trond,
> 
> 在 2025/11/29 12:06, Trond Myklebust 写道:
> > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > 
> > The recent changes to suppress the 'ro' and 'rw' mount options when
> > mounting the same NFS filesystem with different settings are
> > causing
> > confusion with users, and are an unnecessary restriction. They
> > represent
> > a functionality regression.
> > 
> > The following patch set reverts the regressions, before applying a
> > different set of fixes to address the original problem, which was
> > one of
> > the NFSv4 mount automounter code failing to propagate the correct
> > mount
> > options.
> > 
> > Trond Myklebust (6):
> >    Revert "nfs: ignore SB_RDONLY when remounting nfs"
> >    Revert "nfs: clear SB_RDONLY before getting superblock"
> >    Revert "nfs: ignore SB_RDONLY when mounting nfs"
> >    NFS: Automounted filesystem should inherit ro,noexec,nodev,sync
> > flags
> >    NFS: Fix inheritance of the block sizes when automounting
> >    NFS: Fix up the automount fs_context to use the correct cred
> > 
> >   fs/nfs/client.c           | 21 +++++++++++++++++----
> >   fs/nfs/internal.h         |  3 +--
> >   fs/nfs/namespace.c        | 16 +++++++++++++++-
> >   fs/nfs/nfs4client.c       | 18 ++++++++++++++----
> >   fs/nfs/super.c            | 33 +++------------------------------
> >   include/linux/nfs_fs_sb.h |  5 +++++
> >   6 files changed, 55 insertions(+), 41 deletions(-)
> After this series of patches was merged, I found that the issue
> described
> in link [1] has appeared again.
> 
> [root@nfs-client1 ~]# mount /dev/sda /mnt2
> [root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)"
> >/etc/exports
> [root@nfs-client1 ~]# systemctl restart nfs-server
> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
> [root@nfs-client1 ~]# mount | grep nfs4
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1,local_lock=none,addr=127.0.0.1)
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1,local_lock=none,addr=127.0.0.1)
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1,local_lock=none,addr=127.0.0.1)
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1,local_lock=none,addr=127.0.0.1)
> [root@nfs-client1 ~]# uname -a
> Linux nfs-client1 6.19.0-rc7+ #178 SMP PREEMPT_DYNAMIC Thu Jan 29 
> 14:06:54 CST 2026 x86_64 x86_64 x86_64 GNU/Linux
> [root@nfs-client1 ~]#
> 
> [1] 
> https://lore.kernel.org/all/20241114045303.1656426-1-lilingfeng3@huawei.com/
> 
> Thanks,
> Lingfeng.

What does the output of "cat /proc/fs/nfsfs/volumes" show? Does it show
more than 2 devices associated with that fsid?
 
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com

Re: [PATCH 0/6] Fix up NFS client mount option regressions

[Li Lingfeng]

Hi Trond,

在 2026/1/30 0:00, Trond Myklebust 写道:
> On Thu, 2026-01-29 at 15:06 +0800, Li Lingfeng wrote:
>> Hi Trond,
>>
>> 在 2025/11/29 12:06, Trond Myklebust 写道:
>>> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>>>
>>> The recent changes to suppress the 'ro' and 'rw' mount options when
>>> mounting the same NFS filesystem with different settings are
>>> causing
>>> confusion with users, and are an unnecessary restriction. They
>>> represent
>>> a functionality regression.
>>>
>>> The following patch set reverts the regressions, before applying a
>>> different set of fixes to address the original problem, which was
>>> one of
>>> the NFSv4 mount automounter code failing to propagate the correct
>>> mount
>>> options.
>>>
>>> Trond Myklebust (6):
>>>     Revert "nfs: ignore SB_RDONLY when remounting nfs"
>>>     Revert "nfs: clear SB_RDONLY before getting superblock"
>>>     Revert "nfs: ignore SB_RDONLY when mounting nfs"
>>>     NFS: Automounted filesystem should inherit ro,noexec,nodev,sync
>>> flags
>>>     NFS: Fix inheritance of the block sizes when automounting
>>>     NFS: Fix up the automount fs_context to use the correct cred
>>>
>>>    fs/nfs/client.c           | 21 +++++++++++++++++----
>>>    fs/nfs/internal.h         |  3 +--
>>>    fs/nfs/namespace.c        | 16 +++++++++++++++-
>>>    fs/nfs/nfs4client.c       | 18 ++++++++++++++----
>>>    fs/nfs/super.c            | 33 +++------------------------------
>>>    include/linux/nfs_fs_sb.h |  5 +++++
>>>    6 files changed, 55 insertions(+), 41 deletions(-)
>> After this series of patches was merged, I found that the issue
>> described
>> in link [1] has appeared again.
>>
>> [root@nfs-client1 ~]# mount /dev/sda /mnt2
>> [root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)"
>>> /etc/exports
>> [root@nfs-client1 ~]# systemctl restart nfs-server
>> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
>> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
>> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
>> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
>> [root@nfs-client1 ~]# mount | grep nfs4
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1,local_lock=none,addr=127.0.0.1)
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1,local_lock=none,addr=127.0.0.1)
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1,local_lock=none,addr=127.0.0.1)
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1,local_lock=none,addr=127.0.0.1)
>> [root@nfs-client1 ~]# uname -a
>> Linux nfs-client1 6.19.0-rc7+ #178 SMP PREEMPT_DYNAMIC Thu Jan 29
>> 14:06:54 CST 2026 x86_64 x86_64 x86_64 GNU/Linux
>> [root@nfs-client1 ~]#
>>
>> [1]
>> https://lore.kernel.org/all/20241114045303.1656426-1-lilingfeng3@huawei.com/
>>
>> Thanks,
>> Lingfeng.
> What does the output of "cat /proc/fs/nfsfs/volumes" show? Does it show
> more than 2 devices associated with that fsid?
>   

Here is the result of the test:

[root@nfs-client1 ~]# mount /dev/sda /mnt2
[root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)" >/etc/exports
[root@nfs-client1 ~]# systemctl restart nfs-server
[root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
[root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
NV SERVER   PORT DEV          FSID FSC
v4 7f000001  801 0:51         0:0                               no
[root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
[root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
NV SERVER   PORT DEV          FSID FSC
v4 7f000001  801 0:51         0:0                               no
v4 7f000001  801 0:52         0:0                               no
[root@nfs-client1 ~]# mount | grep nfs4
127.0.0.1:/ on /mnt/sdaa type nfs4 
(ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1)
127.0.0.1:/ on /mnt/sdaa type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1)
[root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
[root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
[root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
NV SERVER   PORT DEV          FSID FSC
v4 7f000001  801 0:51         0:0                               no
v4 7f000001  801 0:52         0:0                               no
[root@nfs-client1 ~]# mount | grep nfs4
127.0.0.1:/ on /mnt/sdaa type nfs4 
(ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1)
127.0.0.1:/ on /mnt/sdaa type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1)
127.0.0.1:/ on /mnt/sdaa type nfs4 
(ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1)
127.0.0.1:/ on /mnt/sdaa type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1)
[root@nfs-client1 ~]#

There are only 2 devices associated with that fsid.

Thanks,
Lingfeng.

Re: [PATCH 0/6] Fix up NFS client mount option regressions

[Trond Myklebust]

On Fri, 2026-01-30 at 09:34 +0800, Li Lingfeng wrote:
> Hi Trond,
> 
> 在 2026/1/30 0:00, Trond Myklebust 写道:
> > On Thu, 2026-01-29 at 15:06 +0800, Li Lingfeng wrote:
> > > Hi Trond,
> > > 
> > > 在 2025/11/29 12:06, Trond Myklebust 写道:
> > > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > > 
> > > > The recent changes to suppress the 'ro' and 'rw' mount options
> > > > when
> > > > mounting the same NFS filesystem with different settings are
> > > > causing
> > > > confusion with users, and are an unnecessary restriction. They
> > > > represent
> > > > a functionality regression.
> > > > 
> > > > The following patch set reverts the regressions, before
> > > > applying a
> > > > different set of fixes to address the original problem, which
> > > > was
> > > > one of
> > > > the NFSv4 mount automounter code failing to propagate the
> > > > correct
> > > > mount
> > > > options.
> > > > 
> > > > Trond Myklebust (6):
> > > >     Revert "nfs: ignore SB_RDONLY when remounting nfs"
> > > >     Revert "nfs: clear SB_RDONLY before getting superblock"
> > > >     Revert "nfs: ignore SB_RDONLY when mounting nfs"
> > > >     NFS: Automounted filesystem should inherit
> > > > ro,noexec,nodev,sync
> > > > flags
> > > >     NFS: Fix inheritance of the block sizes when automounting
> > > >     NFS: Fix up the automount fs_context to use the correct
> > > > cred
> > > > 
> > > >    fs/nfs/client.c           | 21 +++++++++++++++++----
> > > >    fs/nfs/internal.h         |  3 +--
> > > >    fs/nfs/namespace.c        | 16 +++++++++++++++-
> > > >    fs/nfs/nfs4client.c       | 18 ++++++++++++++----
> > > >    fs/nfs/super.c            | 33 +++--------------------------
> > > > ----
> > > >    include/linux/nfs_fs_sb.h |  5 +++++
> > > >    6 files changed, 55 insertions(+), 41 deletions(-)
> > > After this series of patches was merged, I found that the issue
> > > described
> > > in link [1] has appeared again.
> > > 
> > > [root@nfs-client1 ~]# mount /dev/sda /mnt2
> > > [root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)"
> > > > /etc/exports
> > > [root@nfs-client1 ~]# systemctl restart nfs-server
> > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# mount | grep nfs4
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > [root@nfs-client1 ~]# uname -a
> > > Linux nfs-client1 6.19.0-rc7+ #178 SMP PREEMPT_DYNAMIC Thu Jan 29
> > > 14:06:54 CST 2026 x86_64 x86_64 x86_64 GNU/Linux
> > > [root@nfs-client1 ~]#
> > > 
> > > [1]
> > > https://lore.kernel.org/all/20241114045303.1656426-1-lilingfeng3@huawei.com/
> > > 
> > > Thanks,
> > > Lingfeng.
> > What does the output of "cat /proc/fs/nfsfs/volumes" show? Does it
> > show
> > more than 2 devices associated with that fsid?
> >   
> 
> Here is the result of the test:
> 
> [root@nfs-client1 ~]# mount /dev/sda /mnt2
> [root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)"
> >/etc/exports
> [root@nfs-client1 ~]# systemctl restart nfs-server
> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
> [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> NV SERVER   PORT DEV          FSID FSC
> v4 7f000001  801 0:51         0:0                               no
> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
> [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> NV SERVER   PORT DEV          FSID FSC
> v4 7f000001  801 0:51         0:0                               no
> v4 7f000001  801 0:52         0:0                               no
> [root@nfs-client1 ~]# mount | grep nfs4
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1)
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1)
> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
> [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> NV SERVER   PORT DEV          FSID FSC
> v4 7f000001  801 0:51         0:0                               no
> v4 7f000001  801 0:52         0:0                               no
> [root@nfs-client1 ~]# mount | grep nfs4
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1)
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1)
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1)
> 127.0.0.1:/ on /mnt/sdaa type nfs4 
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
> 7.0.0.1)
> [root@nfs-client1 ~]#
> 
> There are only 2 devices associated with that fsid.
> 

Then it is working as expected. It's not the kernel's job to stop
people from stacking one mount on top of another. If it were, then the
right place to do that would be in the VFS and not the NFS client.

However the NFS client does try to ensure that mounts of the same
remote filesystem with the same set of mount options gets mapped to the
same super block (and hence device). The exception is if you're playing
with the nosharecache option; in that case you're knowingly asking the
kernel to ignore that constraint.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com

Re: [PATCH 0/6] Fix up NFS client mount option regressions

[Li Lingfeng]

Hi Trond,

在 2026/1/30 9:43, Trond Myklebust 写道:
> On Fri, 2026-01-30 at 09:34 +0800, Li Lingfeng wrote:
>> Hi Trond,
>>
>> 在 2026/1/30 0:00, Trond Myklebust 写道:
>>> On Thu, 2026-01-29 at 15:06 +0800, Li Lingfeng wrote:
>>>> Hi Trond,
>>>>
>>>> 在 2025/11/29 12:06, Trond Myklebust 写道:
>>>>> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>>>>>
>>>>> The recent changes to suppress the 'ro' and 'rw' mount options
>>>>> when
>>>>> mounting the same NFS filesystem with different settings are
>>>>> causing
>>>>> confusion with users, and are an unnecessary restriction. They
>>>>> represent
>>>>> a functionality regression.
>>>>>
>>>>> The following patch set reverts the regressions, before
>>>>> applying a
>>>>> different set of fixes to address the original problem, which
>>>>> was
>>>>> one of
>>>>> the NFSv4 mount automounter code failing to propagate the
>>>>> correct
>>>>> mount
>>>>> options.
>>>>>
>>>>> Trond Myklebust (6):
>>>>>      Revert "nfs: ignore SB_RDONLY when remounting nfs"
>>>>>      Revert "nfs: clear SB_RDONLY before getting superblock"
>>>>>      Revert "nfs: ignore SB_RDONLY when mounting nfs"
>>>>>      NFS: Automounted filesystem should inherit
>>>>> ro,noexec,nodev,sync
>>>>> flags
>>>>>      NFS: Fix inheritance of the block sizes when automounting
>>>>>      NFS: Fix up the automount fs_context to use the correct
>>>>> cred
>>>>>
>>>>>     fs/nfs/client.c           | 21 +++++++++++++++++----
>>>>>     fs/nfs/internal.h         |  3 +--
>>>>>     fs/nfs/namespace.c        | 16 +++++++++++++++-
>>>>>     fs/nfs/nfs4client.c       | 18 ++++++++++++++----
>>>>>     fs/nfs/super.c            | 33 +++--------------------------
>>>>> ----
>>>>>     include/linux/nfs_fs_sb.h |  5 +++++
>>>>>     6 files changed, 55 insertions(+), 41 deletions(-)
>>>> After this series of patches was merged, I found that the issue
>>>> described
>>>> in link [1] has appeared again.
>>>>
>>>> [root@nfs-client1 ~]# mount /dev/sda /mnt2
>>>> [root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)"
>>>>> /etc/exports
>>>> [root@nfs-client1 ~]# systemctl restart nfs-server
>>>> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
>>>> /mnt/sdaa
>>>> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
>>>> /mnt/sdaa
>>>> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
>>>> /mnt/sdaa
>>>> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
>>>> /mnt/sdaa
>>>> [root@nfs-client1 ~]# mount | grep nfs4
>>>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>>>> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
>>>> ,fat
>>>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
>>>> r=12
>>>> 7.0.0.1,local_lock=none,addr=127.0.0.1)
>>>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>>>> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
>>>> ,fat
>>>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
>>>> r=12
>>>> 7.0.0.1,local_lock=none,addr=127.0.0.1)
>>>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>>>> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
>>>> ,fat
>>>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
>>>> r=12
>>>> 7.0.0.1,local_lock=none,addr=127.0.0.1)
>>>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>>>> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
>>>> ,fat
>>>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
>>>> r=12
>>>> 7.0.0.1,local_lock=none,addr=127.0.0.1)
>>>> [root@nfs-client1 ~]# uname -a
>>>> Linux nfs-client1 6.19.0-rc7+ #178 SMP PREEMPT_DYNAMIC Thu Jan 29
>>>> 14:06:54 CST 2026 x86_64 x86_64 x86_64 GNU/Linux
>>>> [root@nfs-client1 ~]#
>>>>
>>>> [1]
>>>> https://lore.kernel.org/all/20241114045303.1656426-1-lilingfeng3@huawei.com/
>>>>
>>>> Thanks,
>>>> Lingfeng.
>>> What does the output of "cat /proc/fs/nfsfs/volumes" show? Does it
>>> show
>>> more than 2 devices associated with that fsid?
>>>    
>> Here is the result of the test:
>>
>> [root@nfs-client1 ~]# mount /dev/sda /mnt2
>> [root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)"
>>> /etc/exports
>> [root@nfs-client1 ~]# systemctl restart nfs-server
>> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
>> [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
>> NV SERVER   PORT DEV          FSID FSC
>> v4 7f000001  801 0:51         0:0                               no
>> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
>> [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
>> NV SERVER   PORT DEV          FSID FSC
>> v4 7f000001  801 0:51         0:0                               no
>> v4 7f000001  801 0:52         0:0                               no
>> [root@nfs-client1 ~]# mount | grep nfs4
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1)
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1)
>> [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
>> [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
>> [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
>> NV SERVER   PORT DEV          FSID FSC
>> v4 7f000001  801 0:51         0:0                               no
>> v4 7f000001  801 0:52         0:0                               no
>> [root@nfs-client1 ~]# mount | grep nfs4
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1)
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1)
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1)
>> 127.0.0.1:/ on /mnt/sdaa type nfs4
>> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fat
>> al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=12
>> 7.0.0.1)
>> [root@nfs-client1 ~]#
>>
>> There are only 2 devices associated with that fsid.
>>
> Then it is working as expected. It's not the kernel's job to stop
> people from stacking one mount on top of another. If it were, then the
> right place to do that would be in the VFS and not the NFS client.
>
> However the NFS client does try to ensure that mounts of the same
> remote filesystem with the same set of mount options gets mapped to the
> same super block (and hence device). The exception is if you're playing
> with the nosharecache option; in that case you're knowingly asking the
> kernel to ignore that constraint.
For local file systems like ext4, when I attempt to mount a file system
as read-only after it has already been mounted for read and write, I
encounter an EBUSY error (from the `get_tree` callback `ext4_get_tree`).

[root@nfs-client1 ~]# mount -o rw /dev/sdb /mnt3
[root@nfs-client1 ~]# mount -o ro /dev/sdb /mnt3
[ 2524.071442][ T1281] sdb: Can't mount, would change RO state
mount: /mnt3: /dev/sdb already mounted on /mnt3.
[root@nfs-client1 ~]# df -Th | grep sdb
/dev/sdb       ext4       20G   28K   19G   1% /mnt3
[root@nfs-client1 ~]#

Do you think NFS should have a similar restriction, allowing only one
mount per mount point?

Thanks,
Lingfeng.

Re: [PATCH 0/6] Fix up NFS client mount option regressions

[Trond Myklebust]

On Fri, 2026-01-30 at 10:41 +0800, Li Lingfeng wrote:
> Hi Trond,
> 
> 在 2026/1/30 9:43, Trond Myklebust 写道:
> > On Fri, 2026-01-30 at 09:34 +0800, Li Lingfeng wrote:
> > > Hi Trond,
> > > 
> > > 在 2026/1/30 0:00, Trond Myklebust 写道:
> > > > On Thu, 2026-01-29 at 15:06 +0800, Li Lingfeng wrote:
> > > > > Hi Trond,
> > > > > 
> > > > > 在 2025/11/29 12:06, Trond Myklebust 写道:
> > > > > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > > > > 
> > > > > > The recent changes to suppress the 'ro' and 'rw' mount
> > > > > > options
> > > > > > when
> > > > > > mounting the same NFS filesystem with different settings
> > > > > > are
> > > > > > causing
> > > > > > confusion with users, and are an unnecessary restriction.
> > > > > > They
> > > > > > represent
> > > > > > a functionality regression.
> > > > > > 
> > > > > > The following patch set reverts the regressions, before
> > > > > > applying a
> > > > > > different set of fixes to address the original problem,
> > > > > > which
> > > > > > was
> > > > > > one of
> > > > > > the NFSv4 mount automounter code failing to propagate the
> > > > > > correct
> > > > > > mount
> > > > > > options.
> > > > > > 
> > > > > > Trond Myklebust (6):
> > > > > >      Revert "nfs: ignore SB_RDONLY when remounting nfs"
> > > > > >      Revert "nfs: clear SB_RDONLY before getting
> > > > > > superblock"
> > > > > >      Revert "nfs: ignore SB_RDONLY when mounting nfs"
> > > > > >      NFS: Automounted filesystem should inherit
> > > > > > ro,noexec,nodev,sync
> > > > > > flags
> > > > > >      NFS: Fix inheritance of the block sizes when
> > > > > > automounting
> > > > > >      NFS: Fix up the automount fs_context to use the
> > > > > > correct
> > > > > > cred
> > > > > > 
> > > > > >     fs/nfs/client.c           | 21 +++++++++++++++++----
> > > > > >     fs/nfs/internal.h         |  3 +--
> > > > > >     fs/nfs/namespace.c        | 16 +++++++++++++++-
> > > > > >     fs/nfs/nfs4client.c       | 18 ++++++++++++++----
> > > > > >     fs/nfs/super.c            | 33 +++---------------------
> > > > > > -----
> > > > > > ----
> > > > > >     include/linux/nfs_fs_sb.h |  5 +++++
> > > > > >     6 files changed, 55 insertions(+), 41 deletions(-)
> > > > > After this series of patches was merged, I found that the
> > > > > issue
> > > > > described
> > > > > in link [1] has appeared again.
> > > > > 
> > > > > [root@nfs-client1 ~]# mount /dev/sda /mnt2
> > > > > [root@nfs-client1 ~]# echo "/mnt2
> > > > > *(rw,no_root_squash,fsid=0)"
> > > > > > /etc/exports
> > > > > [root@nfs-client1 ~]# systemctl restart nfs-server
> > > > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > > > /mnt/sdaa
> > > > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > > > /mnt/sdaa
> > > > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > > > /mnt/sdaa
> > > > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > > > /mnt/sdaa
> > > > > [root@nfs-client1 ~]# mount | grep nfs4
> > > > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
> > > > > hard
> > > > > ,fat
> > > > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clien
> > > > > tadd
> > > > > r=12
> > > > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
> > > > > hard
> > > > > ,fat
> > > > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clien
> > > > > tadd
> > > > > r=12
> > > > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
> > > > > hard
> > > > > ,fat
> > > > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clien
> > > > > tadd
> > > > > r=12
> > > > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
> > > > > hard
> > > > > ,fat
> > > > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clien
> > > > > tadd
> > > > > r=12
> > > > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > > > [root@nfs-client1 ~]# uname -a
> > > > > Linux nfs-client1 6.19.0-rc7+ #178 SMP PREEMPT_DYNAMIC Thu
> > > > > Jan 29
> > > > > 14:06:54 CST 2026 x86_64 x86_64 x86_64 GNU/Linux
> > > > > [root@nfs-client1 ~]#
> > > > > 
> > > > > [1]
> > > > > https://lore.kernel.org/all/20241114045303.1656426-1-lilingfeng3@huawei.com/
> > > > > 
> > > > > Thanks,
> > > > > Lingfeng.
> > > > What does the output of "cat /proc/fs/nfsfs/volumes" show? Does
> > > > it
> > > > show
> > > > more than 2 devices associated with that fsid?
> > > >    
> > > Here is the result of the test:
> > > 
> > > [root@nfs-client1 ~]# mount /dev/sda /mnt2
> > > [root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)"
> > > > /etc/exports
> > > [root@nfs-client1 ~]# systemctl restart nfs-server
> > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> > > NV SERVER   PORT DEV          FSID FSC
> > > v4 7f000001  801 0:51         0:0                             
> > >  no
> > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> > > NV SERVER   PORT DEV          FSID FSC
> > > v4 7f000001  801 0:51         0:0                             
> > >  no
> > > v4 7f000001  801 0:52         0:0                             
> > >  no
> > > [root@nfs-client1 ~]# mount | grep nfs4
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> > > NV SERVER   PORT DEV          FSID FSC
> > > v4 7f000001  801 0:51         0:0                             
> > >  no
> > > v4 7f000001  801 0:52         0:0                             
> > >  no
> > > [root@nfs-client1 ~]# mount | grep nfs4
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > [root@nfs-client1 ~]#
> > > 
> > > There are only 2 devices associated with that fsid.
> > > 
> > Then it is working as expected. It's not the kernel's job to stop
> > people from stacking one mount on top of another. If it were, then
> > the
> > right place to do that would be in the VFS and not the NFS client.
> > 
> > However the NFS client does try to ensure that mounts of the same
> > remote filesystem with the same set of mount options gets mapped to
> > the
> > same super block (and hence device). The exception is if you're
> > playing
> > with the nosharecache option; in that case you're knowingly asking
> > the
> > kernel to ignore that constraint.
> For local file systems like ext4, when I attempt to mount a file
> system
> as read-only after it has already been mounted for read and write, I
> encounter an EBUSY error (from the `get_tree` callback
> `ext4_get_tree`).
> 
> [root@nfs-client1 ~]# mount -o rw /dev/sdb /mnt3
> [root@nfs-client1 ~]# mount -o ro /dev/sdb /mnt3
> [ 2524.071442][ T1281] sdb: Can't mount, would change RO state
> mount: /mnt3: /dev/sdb already mounted on /mnt3.
> [root@nfs-client1 ~]# df -Th | grep sdb
> /dev/sdb       ext4       20G   28K   19G   1% /mnt3
> [root@nfs-client1 ~]#
> 
> Do you think NFS should have a similar restriction, allowing only one
> mount per mount point?

Why would we do that?

The above is a reflection of the fact that for ext4, the block device
can only be associated with one filesystem. After you've mounted that
block device in one place, you can't mount it read-only anywhere else.

The only way to create both a read-only and a read-write mount with
ext4 is to use a bind mount to create the read-only mount point.

NFS has no need for that restriction, so what would be the point of
duplicating it? In particular why would we want to break backward
compatibility for people who may already be relying on the current
behaviour?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com