NFS Configuration - Revision history

Qadmin: Scope the read-only claims to the kernel NFS server; share-level Read Only is not confirmed to reach Ganesha exports (QSTOR-12352, QSTOR-12418)

2026-09-03T06:02:37Z

Scope the read-only claims to the kernel NFS server; share-level Read Only is not confirmed to reach Ganesha exports (QSTOR-12352, QSTOR-12418)

← Older revision		Revision as of 06:02, 3 September 2026
Line 91:		Line 91:
	\| Kerberos security \|\| Available \|\| Not available; every generated export is <code>sectype = sys</code>		\| Kerberos security \|\| Available \|\| Not available; every generated export is <code>sectype = sys</code>
	\|-		\|-
	\| ~~Read~~-only, root squash, client filter \|\| Honoured \|\| Honoured		\| Per-client read-only, root squash, client filter \|\| Honoured \|\| Honoured
	\|-		\|-
	\| Full port range, async writes, subtree checks, custom export options, Filter Priority \|\| Honoured \|\| '''Not applied.''' These are accepted and stored, and the WUI still shows them, but they are not written into the Ganesha configuration		\| Full port range, async writes, subtree checks, custom export options, Filter Priority \|\| Honoured \|\| '''Not applied.''' These are accepted and stored, and the WUI still shows them, but they are not written into the Ganesha configuration
Line 301:		Line 301:
	! Export option !! Set by !! What it does		! Export option !! Set by !! What it does
	\|-		\|-
	\| <code>rw</code> / <code>ro</code> \|\| '''Read Only''' on the rule, or '''Read Only''' on the share -- the ~~share-level setting wins~~ \|\| Whether the client may write.		\| <code>rw</code> / <code>ro</code> \|\| '''Read Only''' on the rule. On a scale-up share, '''Read Only''' on the share itself also forces <code>ro</code> regardless of the rule \|\| Whether the client may write.
	\|-		\|-
	\| <code>insecure</code> / <code>secure</code> \|\| '''Allow Full Port Range Access''' -- ticked gives <code>insecure</code> \|\| <code>secure</code> requires the client's requests to come from a reserved source port below 1024. Many clients do not use one by default, including macOS without <code>resvport</code> and a good number of containerised and appliance clients, so <code>secure</code> is a common cause of an unexplained permission denied.		\| <code>insecure</code> / <code>secure</code> \|\| '''Allow Full Port Range Access''' -- ticked gives <code>insecure</code> \|\| <code>secure</code> requires the client's requests to come from a reserved source port below 1024. Many clients do not use one by default, including macOS without <code>resvport</code> and a good number of containerised and appliance clients, so <code>secure</code> is a common cause of an unexplained permission denied.

Qadmin: Give NFS Server Type its own row in the apply table with the real client impact, and point it at the supported-topology section (QSTOR-12352)

2026-09-03T05:46:32Z

Give NFS Server Type its own row in the apply table with the real client impact, and point it at the supported-topology section (QSTOR-12352)

← Older revision		Revision as of 05:46, 3 September 2026
Line 115:		Line 115:
	! Setting !! Default !! Notes		! Setting !! Default !! Notes
	\|-		\|-
	\| '''NFS Server Type''' \|\| Scale-up \|\| Scale-up or Scale-out, as described above.		\| '''NFS Server Type''' \|\| Scale-up \|\| Scale-up or Scale-out, as described above. Set it to match the kind of Storage Pool the node serves NFS from; changing it takes shares on the other kind offline for NFS clients.
	\|-		\|-
	\| '''NFS Protocol Mode''' \|\| NFS v3/v4 \|\| NFS v3/v4, NFS v3, or NFS v4. See [[#NFS protocol versions\|NFS protocol versions]].		\| '''NFS Protocol Mode''' \|\| NFS v3/v4 \|\| NFS v3/v4, NFS v3, or NFS v4. See [[#NFS protocol versions\|NFS protocol versions]].
Line 357:		Line 357:
	\| Create, modify, delete, enable, disable, snapshot, clone or rename a share; cross-mount and snapshot browsing options; a share's NFS security policy \|\| Same \|\| '''None'''		\| Create, modify, delete, enable, disable, snapshot, clone or rename a share; cross-mount and snapshot browsing options; a share's NFS security policy \|\| Same \|\| '''None'''
	\|-		\|-
	\| '''Default Security Policy''' ~~and~~ '''NFS Server Type''' in the NFS Services Configuration dialog \|\| ~~Same~~ \|\| ~~None from~~ the ~~reload itself. Changing~~ the ~~server type does swap which daemon~~ is ~~serving~~.		\| '''Default Security Policy''' in the NFS Services Configuration dialog \|\| Same \|\| '''None'''
			\|-
			\| '''NFS Server Type''' in the NFS Services Configuration dialog \|\| The other server is stopped, disabled and masked and the selected one takes over port 2049 \|\| '''Shares on the other kind of pool stop being served over NFS''' until the setting is put back. See [[#A node serves NFS from scale-up pools or scale-out pools, not both\|A node serves NFS from scale-up pools or scale-out pools, not both]]
	\|-		\|-
	\| '''NFS Protocol Mode''', '''Enable Kerberos Security''', '''Kerberos Mode''', '''Disable NFSv4 /export Browsing''', '''Manage GIDs''' \|\| Configuration files are written and <code>nfs-server</code> is restarted \|\| '''Momentary interruption''' for every NFS client on that system		\| '''NFS Protocol Mode''', '''Enable Kerberos Security''', '''Kerberos Mode''', '''Disable NFSv4 /export Browsing''', '''Manage GIDs''' \|\| Configuration files are written and <code>nfs-server</code> is restarted \|\| '''Momentary interruption''' for every NFS client on that system
Line 364:		Line 366:
	\|}		\|}

	~~The five settings in the fourth row~~ are the only ~~ones~~ in the dialog that bounce the service, and the dialog restarts it only when one of them actually changes -- reapplying the dialog with nothing altered does not interrupt anything.		'''NFS Protocol Mode''', '''Enable Kerberos Security''', '''Kerberos Mode''', '''Disable NFSv4 /export Browsing''' and '''Manage GIDs''' are the only settings in the dialog that bounce the service, and the dialog restarts it only when one of them actually changes -- reapplying the dialog with nothing altered does not interrupt anything.

	A reload really is transparent: an active NFSv3 mount and an active NFSv4.2 mount both kept serving reads across repeated export regenerations while client rules were added and removed and snapshot sub-exports appeared, with no error and no remount.		A reload really is transparent: an active NFSv3 mount and an active NFSv4.2 mount both kept serving reads across repeated export regenerations while client rules were added and removed and snapshot sub-exports appeared, with no error and no remount.

Qadmin: State the supported topology explicitly -- a node serves NFS from scale-up or scale-out pools, not both, with the reasons -- and stop presenting the legacy qs-util nfsstandard/nfsganesha verbs as a way to switch modes; the NFS Services Configuration dialog is the supported path (QSTOR-12352)

2026-09-03T05:45:12Z

State the supported topology explicitly -- a node serves NFS from scale-up or scale-out pools, not both, with the reasons -- and stop presenting the legacy qs-util nfsstandard/nfsganesha verbs as a way to switch modes; the NFS Services Configuration dialog is the supported path (QSTOR-12352)

← Older revision		Revision as of 05:45, 3 September 2026
Line 8:		Line 8:
	! Section !! Purpose		! Section !! Purpose
	\|-		\|-
	\| [[#The two NFS server implementations\|The two NFS server implementations]] \|\| Scale-up versus scale-out, ~~and~~ which storage architecture selects which		\| [[#The two NFS server implementations\|The two NFS server implementations]] \|\| Scale-up versus scale-out, which storage architecture selects which, and why a node serves one or the other
	\|-		\|-
	\| [[#Configuring the NFS service\|Configuring the NFS service]] \|\| The NFS Services Configuration dialog, field by field		\| [[#Configuring the NFS service\|Configuring the NFS service]] \|\| The NFS Services Configuration dialog, field by field
Line 57:		Line 57:
	</pre>		</pre>

	Selecting '''Scale-out''' moves NFS-Ganesha to 2049 with NFSv3 and NFSv4 enabled, and stops, disables and masks the kernel NFS server. '''On a system that also has ZFS Storage Pools, that takes every share on them offline for NFS clients''' -- they remain available over SMB. There is no confirmation prompt for this, and nothing validates the choice against the pools that actually exist, so treat Scale-out as a decision about the whole appliance rather than a per-share option. On a system with no Ceph storage the Ganesha service is left masked and not running.		Selecting '''Scale-out''' moves NFS-Ganesha to 2049 with NFSv3 and NFSv4 enabled, and stops, disables and masks the kernel NFS server. On a system with no Ceph storage the Ganesha service is left masked and not running.

	QuantaStor ~~selects~~ Scale-out for you in one ~~situation~~: when a Ceph file system or Ceph object pool is created on a system that has '''no''' ZFS Storage Pools. If ZFS pools are present it leaves the setting alone and raises a warning alert reading ''"SCALE-UP pool(s) present on local system. Not configuring SCALE-OUT NFS settings."'' ~~Everywhere else~~ the ~~setting is yours to make~~.		=== A node serves NFS from scale-up pools or scale-out pools, not both ===

			'''This is a supported-configuration constraint, not a limitation to design around.''' A given storage system serves NFS from ZFS Storage Pools or from CephFS pools -- whichever its NFS Server Type selects -- and not from both at once. The reasons are specific to each server:

			* '''CephFS does not work properly behind the kernel NFS server.''' Re-exporting a CephFS mount through <code>nfsd</code> is not a supported combination, which is why the scale-out path exists at all.
			* '''NFS-Ganesha has too many gaps to put in front of a scale-up pool.''' The comparison below shows them: no NFSv3 on the alternate port, no NLM locking, no Kerberos, and a set of per-client export options it does not implement. A ZFS pool served through Ganesha would lose capability that scale-up administrators depend on.

			So the mode switch masking the other server is the '''intended''' behaviour, and the right way to read it. Plan a node as a scale-up NAS or a scale-out NAS and set the NFS Server Type to match. If you need both architectures, use separate storage systems -- they can be members of the same grid.

			The practical consequence to plan for is that '''switching the mode on a node that has shares on the other kind of pool takes those shares offline for NFS clients''', immediately and without a confirmation prompt. They remain reachable over SMB. Check what the node is serving before you change the setting.

			QuantaStor sets Scale-out for you in the one case where it is unambiguous: when a Ceph file system or Ceph object pool is created on a system that has '''no''' ZFS Storage Pools. If ZFS pools are present it leaves the setting alone and raises a warning alert reading ''"SCALE-UP pool(s) present on local system. Not configuring SCALE-OUT NFS settings."'' -- which is the same constraint, enforced from the other direction.

	For the Ceph side of the picture, see [[Scale-out File Setup (ceph)]].		For the Ceph side of the picture, see [[Scale-out File Setup (ceph)]].
Line 381:		Line 392:
	There is no <code>qs</code> command for this operation. It is available from the WUI and the REST API only.		There is no <code>qs</code> command for this operation. It is available from the WUI and the REST API only.

	~~Two~~ appliance-side ~~commands cover cases~~ the dialog does not. <code>qs-util nfsstandard</code> and <code>qs-util nfsganesha</code> apply the Scale-up and Scale-out server configurations directly, and are the way back when the configuration on disk and the recorded server type have diverged. <code>qs-util nfsrdma</code> enables NFS over RDMA -- it loads the <code>rpcrdma</code> module, sets <code>rdma=y</code> and <code>rdma-port=20049</code> in {{Code\|1=/etc/nfs.conf}} after backing the file up, restarts the server and verifies the RDMA port came up. RDMA has no equivalent in the WUI, and it needs lossless or PFC configured on both the appliance and the client to be worth having.		One appliance-side command covers a case the dialog does not. <code>qs-util nfsrdma</code> enables NFS over RDMA: it loads the <code>rpcrdma</code> module, sets <code>rdma=y</code> and <code>rdma-port=20049</code> in {{Code\|1=/etc/nfs.conf}} after backing the file up, restarts the server and verifies the RDMA port came up. RDMA has no equivalent in the WUI, and it needs lossless or PFC configured on both the appliance and the client to be worth having.

			'''<code>qs-util nfsstandard</code> and <code>qs-util nfsganesha</code> are legacy and should not be used.''' They predate NFS server mode being managed properly, and the '''NFS Server Type''' setting in the [[#Configuring the NFS service\|NFS Services Configuration]] dialog is the supported way to switch between the two servers. Use the dialog.

	== NFS over an HA storage pool ==		== NFS over an HA storage pool ==
Line 519:		Line 532:
	</pre>		</pre>

	With the server type set to '''Scale-out''', Ganesha owns 2049 and no port override is needed. NFSv3 is not an option against the alternate port.		With the server type set to '''Scale-out''', Ganesha owns 2049 and no port override is needed, and this is the configuration to be in if a node is serving CephFS shares over NFS -- see [[#A node serves NFS from scale-up pools or scale-out pools, not both\|A node serves NFS from scale-up pools or scale-out pools, not both]]. NFSv3 is not an option against the alternate port.

	=== Windows clients ===		=== Windows clients ===

Qadmin: Restore the qs_nfsv4_sessions.sh diagnostic with its correct installed path under /opt/osnexus/quantastor/bin (QSTOR-12352)

2026-09-03T05:32:29Z

Restore the qs_nfsv4_sessions.sh diagnostic with its correct installed path under /opt/osnexus/quantastor/bin (QSTOR-12352)

← Older revision		Revision as of 05:32, 3 September 2026
Line 590:		Line 590:
	=== Finding out who is connected ===		=== Finding out who is connected ===

	QuantaStor tracks '''SMB''' sessions only. The '''SMB Sessions''' tab and <code>[[QuantaStor CLI Command Reference#share-session-list\|qs share-session-list]]</code> do not report NFS clients, so do not read an empty list as nobody being mounted. For NFS, use the '''NFS Stats''' tab of the Share Dashboard for throughput and operation rates, and <code>showmount -a</code> on the appliance for NFSv3 mounts.		QuantaStor tracks '''SMB''' sessions only. The '''SMB Sessions''' tab and <code>[[QuantaStor CLI Command Reference#share-session-list\|qs share-session-list]]</code> do not report NFS clients, so do not read an empty list as nobody being mounted. For NFS, use the '''NFS Stats''' tab of the Share Dashboard for throughput and operation rates, and <code>showmount -a</code> for NFSv3 mounts.

			For NFSv4 the appliance ships a script that correlates each client's open files back to the share and dataset holding them, which is the only way to answer "who has this file open" over NFSv4. Run it as root on the appliance:

			<pre style="font-size: smaller">
			/opt/osnexus/quantastor/bin/qs_nfsv4_sessions.sh
			/opt/osnexus/quantastor/bin/qs_nfsv4_sessions.sh -v
			/opt/osnexus/quantastor/bin/qs_nfsv4_sessions.sh --path=/mnt/storage-pools/
			</pre>

			It prints one row per open file as ''client IP \| open file \| mountpoint or dataset''. <code>-v</code> adds debugging detail and <code>--path=</code> narrows it to one subtree; the default is all of <code>/mnt/storage-pools/</code>. It reads NFSv4 client state out of the kernel, so it needs root and reports nothing for NFSv3 mounts.

	=== Slow NFS writes ===		=== Slow NFS writes ===

Qadmin: Rewrite from the product: correct the two server implementations and how one is selected, the NFSv4 mount path (/export/, not /), the root_squash and secure/insecure defaults, rule-order semantics, and the scale-out port; add the NFS Services Configuration dialog field by field, the generated export lines and their option order, reload-vs-restart, HA failover behaviour, ID mapping and Manage GIDs, and the _snaps/.zfs sub-exports (QSTOR-12352)

2026-09-03T05:30:06Z

Rewrite from the product: correct the two server implementations and how one is selected, the NFSv4 mount path (/export/<share>, not /<share>), the root_squash and secure/insecure defaults, rule-order semantics, and the scale-out port; add the NFS Services Configuration dialog field by field, the generated export lines and their option order, reload-vs-restart, HA failover behaviour, ID mapping and Manage GIDs, and the _snaps/.zfs sub-exports (QSTOR-12352)

Show changes

Qadmin: QSTOR-11826: Fix CLI command bugs (live-tested against 10.0.8.110): --filter replaces --client-filter, --rdonly replaces --read-only, share-client-list/share-session-list replace enum, --disable-nfs-snap-dir fixes typo, --disable-nfs-hidden-dir-browsing replaces nonexistent --enable-nfs-snap-browsing, --share-session replaces --session, note NFS mode/Kerberos are WUI-only settings

2026-06-17T16:06:17Z

QSTOR-11826: Fix CLI command bugs (live-tested against 10.0.8.110): --filter replaces --client-filter, --rdonly replaces --read-only, share-client-list/share-session-list replace enum, --disable-nfs-snap-dir fixes typo, --disable-nfs-hidden-dir-browsing replaces nonexistent --enable-nfs-snap-browsing, --share-session replaces --session, note NFS mode/Kerberos are WUI-only settings

← Older revision		Revision as of 16:06, 17 June 2026
Line 38:		Line 38:
	'''Navigation:''' System Management → Storage System → (right-click) → Modify Network Share Service Settings		'''Navigation:''' System Management → Storage System → (right-click) → Modify Network Share Service Settings

	'''CLI:'''		'''CLI — view current NFS service configuration:'''
	<pre>		<pre>
	# View ~~current NFS service configuration~~		# View system info including "Network Share Service Config" section
	qs ~~network-share-service-config~~-get		qs system-get
			</pre>
	~~# Allow both NFSv3 and NFSv4 clients (default)~~
	~~qs network-share-service-config-modify --nfs-mode=v3v4~~

	~~# NFSv4 only~~
	~~qs network-share-service-config-modify --nfs-mode=v4~~

	~~# NFSv3 only~~		'''Note:''' Changing the NFS protocol mode (v3v4, v4, v3) is performed via the WUI — there is no CLI command for this setting.
	~~qs network-share-service-config-modify --nfs-~~mode=v3
	~~</pre>~~

	{\| class="wikitable"		{\| class="wikitable"
Line 93:		Line 86:
	'''CLI:'''		'''CLI:'''
	<pre>		<pre>
	# Add read-write access from a subnet (no root squash — default)		# Add read-write access from a subnet (root squash is NFS default)
	qs share-client-add --share=share1 -~~-client~~-filter=192.168.10.0/24		qs share-client-add --share=share1 --filter=192.168.10.0/24

	# Add read-only access from a second subnet		# Add read-only access from a second subnet
	qs share-client-add --share=share1 -~~-client~~-filter=10.0.0.0/8 --~~read-only~~=true		qs share-client-add --share=share1 --filter=10.0.0.0/8 --rdonly=true

	# Add a specific host ~~with~~ root squash ~~enabled~~		# Add a specific host; disable root squash explicitly
	qs share-client-add --share=share1 -~~-client~~-filter=192.168.10.50 --~~root-squash~~=~~true~~		qs share-client-add --share=share1 --filter=192.168.10.50 --options=no_root_squash

	# List current NFS client rules for a share		# List current NFS client rules for a share
	qs share-client-~~enum~~ --share=share1		qs share-client-list --share=share1

	# Modify an existing rule		# Modify an existing rule (enable async writes)
	qs share-client-modify --share=share1 -~~-client~~-filter=192.168.10.0/24 --async=true		qs share-client-modify --share=share1 --filter=192.168.10.0/24 --async=true

	# Remove a rule		# Remove a rule
	qs share-client-remove --share=share1 -~~-client~~-filter=192.168.10.0/24		qs share-client-remove --share=share1 --filter=192.168.10.0/24
	</pre>		</pre>

	=== Access Priority ===		=== Access Priority ===

	When multiple client filter rules match a client's IP address, the rule ~~with the lowest priority number is applied first. Use this~~ to ~~grant elevated access to specific hosts within~~ a broader subnet:		When multiple client filter rules match a client's IP address, Linux NFS applies the most-specific (longest-prefix) match. Add a more specific rule for a single host to override a broader subnet rule:

	<pre>		<pre>
	# ~~Priority 1: specific~~ host gets read-write + no_root_squash		# Specific host gets read-write + no_root_squash (more specific, matched first)
	qs share-client-add --share=share1 -~~-client~~-filter=192.168.10.100 --~~priority~~=1		qs share-client-add --share=share1 --filter=192.168.10.100 --options=no_root_squash

	# ~~Priority 2: rest of~~ subnet gets read-only		# Broader subnet gets read-only
	qs share-client-add --share=share1 -~~-client~~-filter=192.168.10.0/24 --~~read-only~~=true ~~--priority=2~~		qs share-client-add --share=share1 --filter=192.168.10.0/24 --rdonly=true
	</pre>		</pre>

Line 204:		Line 197:
	'''Navigation:''' System Management → Storage System → (right-click) → Modify Network Share Service Settings → Enable Kerberos		'''Navigation:''' System Management → Storage System → (right-click) → Modify Network Share Service Settings → Enable Kerberos

	'''~~CLI~~:'''		'''Note:''' Enabling NFS Kerberos system-wide is a WUI-only operation — navigate to System Management → Storage System → (right-click) → Modify Network Share Service Settings → Enable Kerberos. Select the Kerberos mode (krb5, krb5i, or krb5p) from the NFS Security Policy dropdown.
	~~<pre>~~
	~~# Enable~~ Kerberos ~~with integrity mode (recommended)~~
	~~qs network~~-~~share~~-~~service-config-modify --nfs4-kerberos-enabled=true --nfs-kerberos~~-mode=krb5i
	~~</pre>~~

	=== Per-Share Security Policy ===		=== Per-Share Security Policy ===
Line 247:		Line 236:
	'''CLI:'''		'''CLI:'''
	<pre>		<pre>
	qs share-modify --share=share1 --~~enable~~-nfs-~~snap~~-browsing=true		# Enable .zfs snapshot directory browsing for a share
			qs share-modify --share=share1 --disable-nfs-hidden-dir-browsing=false

			# Disable .zfs snapshot directory browsing
			qs share-modify --share=share1 --disable-nfs-hidden-dir-browsing=true
	</pre>		</pre>

Line 269:		Line 262:
	To disable <code>_snaps</code> visibility for a share:		To disable <code>_snaps</code> visibility for a share:
	<pre>		<pre>
	qs share-modify --share=share1 --disable-nfs-~~snaps~~-dir=true		qs share-modify --share=share1 --disable-nfs-snap-dir=true
			</pre>

			To re-enable:
			<pre>
			qs share-modify --share=share1 --disable-nfs-snap-dir=false
	</pre>		</pre>

Line 372:		Line 370:
	<pre>		<pre>
	# List all active NFS and SMB sessions		# List all active NFS and SMB sessions
	qs share-session-~~enum~~		qs share-session-list

	# Get details for a specific session		# Get details for a specific session
	qs share-session-get --session=<session-id>		qs share-session-get --share-session=<session-id>
	</pre>		</pre>

Line 394:		Line 392:
	=== Share Not Visible to Clients ===		=== Share Not Visible to Clients ===

	# Verify the share has at least one NFS client rule: <code>qs share-client-~~enum~~ --share=share1</code>		# Verify the share has at least one NFS client rule: <code>qs share-client-list --share=share1</code>
	# Confirm the NFS service is running: <code>systemctl status nfs-server</code> (scale-up) or <code>systemctl status nfs-ganesha</code> (scale-out)		# Confirm the NFS service is running: <code>systemctl status nfs-server</code> (scale-up) or <code>systemctl status nfs-ganesha</code> (scale-out)
	# Test connectivity on port 2049: <code>nc -zv 192.168.1.100 2049</code>		# Test connectivity on port 2049: <code>nc -zv 192.168.1.100 2049</code>

Qadmin: Full rewrite: modernize for NFSv4, current distros, Kerberos, Ganesha, performance options, troubleshooting

2026-06-17T03:17:39Z

Full rewrite: modernize for NFSv4, current distros, Kerberos, Ganesha, performance options, troubleshooting

Show changes

Qadmin: /* no_root_squash Configuration */

2022-10-13T01:21:38Z

no_root_squash Configuration

← Older revision		Revision as of 01:21, 13 October 2022
Line 7:		Line 7:
	To configure the 'no_root_squash' option first go the the QuantaStor web management interface and expand the tree where you see ''Network Shares''. In this example, 'share1' and under there you'll see a host access entry called \[public\]. Right-click on that and choose 'Modify NFS Client Access...'. In this screen input no_root_squash into the Custom NFS Export Options section. This will allow you to modify files in the share. Second you'll probably want to enable 'Async Writes' which will boost performance a bit. Once you're done click 'OK'.		To configure the 'no_root_squash' option first go the the QuantaStor web management interface and expand the tree where you see ''Network Shares''. In this example, 'share1' and under there you'll see a host access entry called \[public\]. Right-click on that and choose 'Modify NFS Client Access...'. In this screen input no_root_squash into the Custom NFS Export Options section. This will allow you to modify files in the share. Second you'll probably want to enable 'Async Writes' which will boost performance a bit. Once you're done click 'OK'.

	[[File:Modify NFS Client Access ~~Web~~.jpg\|712px]]		[[File:Modify NFS Client Access Web6.jpg\|712px]]

	==== NFSv4 Mount Procedure ====		==== NFSv4 Mount Procedure ====

Qadmin: /* no_root_squash Configuration */

2020-01-30T23:21:57Z

no_root_squash Configuration

← Older revision		Revision as of 23:21, 30 January 2020
Line 7:		Line 7:
	To configure the 'no_root_squash' option first go the the QuantaStor web management interface and expand the tree where you see ''Network Shares''. In this example, 'share1' and under there you'll see a host access entry called \[public\]. Right-click on that and choose 'Modify NFS Client Access...'. In this screen input no_root_squash into the Custom NFS Export Options section. This will allow you to modify files in the share. Second you'll probably want to enable 'Async Writes' which will boost performance a bit. Once you're done click 'OK'.		To configure the 'no_root_squash' option first go the the QuantaStor web management interface and expand the tree where you see ''Network Shares''. In this example, 'share1' and under there you'll see a host access entry called \[public\]. Right-click on that and choose 'Modify NFS Client Access...'. In this screen input no_root_squash into the Custom NFS Export Options section. This will allow you to modify files in the share. Second you'll probably want to enable 'Async Writes' which will boost performance a bit. Once you're done click 'OK'.

	[[File:Modify NFS Client Access Web.jpg]]		[[File:Modify NFS Client Access Web.jpg\|712px]]

	==== NFSv4 Mount Procedure ====		==== NFSv4 Mount Procedure ====

Qadmin: /* no_root_squash Configuration */

2020-01-30T23:21:16Z

no_root_squash Configuration

← Older revision		Revision as of 23:21, 30 January 2020
Line 7:		Line 7:
	To configure the 'no_root_squash' option first go the the QuantaStor web management interface and expand the tree where you see ''Network Shares''. In this example, 'share1' and under there you'll see a host access entry called \[public\]. Right-click on that and choose 'Modify NFS Client Access...'. In this screen input no_root_squash into the Custom NFS Export Options section. This will allow you to modify files in the share. Second you'll probably want to enable 'Async Writes' which will boost performance a bit. Once you're done click 'OK'.		To configure the 'no_root_squash' option first go the the QuantaStor web management interface and expand the tree where you see ''Network Shares''. In this example, 'share1' and under there you'll see a host access entry called \[public\]. Right-click on that and choose 'Modify NFS Client Access...'. In this screen input no_root_squash into the Custom NFS Export Options section. This will allow you to modify files in the share. Second you'll probably want to enable 'Async Writes' which will boost performance a bit. Once you're done click 'OK'.

	[[File:~~no_root_squash~~.jpg~~\|800px\|NFS v4 share configuration~~]]		[[File:Modify NFS Client Access Web.jpg]]

	==== NFSv4 Mount Procedure ====		==== NFSv4 Mount Procedure ====