NFSv4 fsid=0 export still necessary?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folks,

several NFSv4-HOWTOs in the net require to export a root directory with fsid=0 first. Other exported directory trees should be nested within this root directory and exported with nohide. AFAIU the advan- tage of the root dir is that the client can mount "server:/somedir" instead of "server:/remote_mount_point/somedir".

Question: Is the common root directory optional? Since NFSv3 doesn't support this name space feature, wouldn't it be more wise to omit the root directory?

Any helpful comment would be highly appreciated

Harri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7aBlAACgkQUTlbRTxpHjeO0wCggdEdfcBzswibHAOG6w2xJa5r B4QAn3MsYZR7xCh60c1X4AsNLnutXSPI
=nEBr
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

No, the fsid=0 export option is no longer necessary to make v4 exports compatible with v2/v3 exports. When the fsid option is not set, the default root is define as "/" which allows the v4 clients to mount the same exports as does the v2/v3 clients.

Now if you do not what "/" as your default root, you can set fsid to something like fsid=/export. This will change to default root to the /export directory which means your v4 clients will only be able to access exports under the /export directory.

Quoted 10 lines · Steve Dickson

No, the fsid=0 export option is no longer necessary to make v4 exports compatible with v2/v3 exports. When the fsid option is not set, the default root is define as "/" which allows the v4 clients to mount the same exports as does the v2/v3 clients.

Now if you do not what "/" as your default root, you can set fsid to something like fsid=/export. This will change to default root to the /export directory which means your v4 clients will only be able to access exports under the /export directory.

I actually have some old patches that allow you to use an alternate root for all NFS versions; you'd do something like:

	/exports	*(ro, root)
	/exports/foo	*(rw)
	/exports/bar	*(rw)

and then a v2, v3, or v4 client would mount server:/foo or server:/bar.

But that was just a fun project, it wasn't clear to me whether anyone wanted it particularly.

Also, that didn't seem like a great user interface. I'd rather have something like

	rootpath=/exports
	foo	*(rw)
	bar	*(rw)

Actually, as long as we were doing that I'd rather replace /etc/exports entirely; maybe do something like

	[nfsd]
		rootpath=/exports
	[export "foo"]
		clients=*
		options=rw
	[exports "bar"]
		clients=*
		options=rw

And also use the same file for other nfsd parameters:

	[nfsd]
		versions=2,3,4,4.1
		threads=8
		rootpath=/exports
	[export "foo"]
		...

Quoted 43 lines · J. Bruce Fields

Quoted 10 lines · Steve Dickson

No, the fsid=0 export option is no longer necessary to make v4 exports compatible with v2/v3 exports. When the fsid option is not set, the default root is define as "/" which allows the v4 clients to mount the same exports as does the v2/v3 clients.

Now if you do not what "/" as your default root, you can set fsid to something like fsid=/export. This will change to default root to the /export directory which means your v4 clients will only be able to access exports under the /export directory.

I actually have some old patches that allow you to use an alternate root for all NFS versions; you'd do something like:

	/exports	*(ro, root)
	/exports/foo	*(rw)
	/exports/bar	*(rw)

and then a v2, v3, or v4 client would mount server:/foo or server:/bar.

But that was just a fun project, it wasn't clear to me whether anyone wanted it particularly.

Also, that didn't seem like a great user interface. I'd rather have something like

	rootpath=/exports
	foo	*(rw)
	bar	*(rw)

Actually, as long as we were doing that I'd rather replace /etc/exports entirely; maybe do something like

	[nfsd]
		rootpath=/exports
	[export "foo"]
		clients=*
		options=rw
	[exports "bar"]
		clients=*
		options=rw

Quoted 8 lines

And also use the same file for other nfsd parameters:

	[nfsd]
		versions=2,3,4,4.1
		threads=8
		rootpath=/exports
	[export "foo"]
		...

I kinda like this idea... In the systemd world, its less error prone to have daemons read their own configuration files...

Where would this new file live and what would be called?

Quoted 54 lines · Steve Dickson

Quoted 51 lines · J. Bruce Fields

Quoted 10 lines · Steve Dickson

No, the fsid=0 export option is no longer necessary to make v4 exports compatible with v2/v3 exports. When the fsid option is not set, the default root is define as "/" which allows the v4 clients to mount the same exports as does the v2/v3 clients.

Now if you do not what "/" as your default root, you can set fsid to something like fsid=/export. This will change to default root to the /export directory which means your v4 clients will only be able to access exports under the /export directory.

I actually have some old patches that allow you to use an alternate root for all NFS versions; you'd do something like:

	/exports	*(ro, root)
	/exports/foo	*(rw)
	/exports/bar	*(rw)

and then a v2, v3, or v4 client would mount server:/foo or server:/bar.

But that was just a fun project, it wasn't clear to me whether anyone wanted it particularly.

Also, that didn't seem like a great user interface. I'd rather have something like

	rootpath=/exports
	foo	*(rw)
	bar	*(rw)

Actually, as long as we were doing that I'd rather replace /etc/exports entirely; maybe do something like

	[nfsd]
		rootpath=/exports
	[export "foo"]
		clients=*
		options=rw
	[exports "bar"]
		clients=*
		options=rw

And also use the same file for other nfsd parameters:

	[nfsd]
		versions=2,3,4,4.1
		threads=8
		rootpath=/exports
	[export "foo"]
		...

Quoted 5 lines

I kinda like this idea... In the systemd world, its less error prone to have daemons read their own configuration files...

Where would this new file live and what would be called?

I'm not sure.... Where did you end up putting the file for nfs mount configuration?