Network Shares - Revision history

Qadmin: Related pages: scale-up and scale-out share replication

2026-09-28T16:43:20Z

Related pages: scale-up and scale-out share replication

← Older revision		Revision as of 16:43, 28 September 2026
Line 775:		Line 775:
	* [[Enabling Global MMC Management]] -- enabling MMC share management for a whole system		* [[Enabling Global MMC Management]] -- enabling MMC share management for a whole system
	* [[Snapshot Schedules]] -- scheduled snapshots and retention		* [[Snapshot Schedules]] -- scheduled snapshots and retention
			* [[Remote-replication (DR)]] -- replicating shares on scale-up (ZFS) pools to another system
			* [[Scale-out File Replication]] -- replicating shares on scale-out (CephFS) pools to another Ceph Cluster
	* [[Backup Policies]] -- copying share data off the system		* [[Backup Policies]] -- copying share data off the system
	* [[Cloud Containers / NAS Gateway]] -- cloud containers and the share used as their cache		* [[Cloud Containers / NAS Gateway]] -- cloud containers and the share used as their cache

Qadmin: Link multi-admin approval to Security Configuration#Multi-admin Approvals

2026-09-28T16:40:42Z

Link multi-admin approval to Security Configuration#Multi-admin Approvals

← Older revision		Revision as of 16:40, 28 September 2026
Line 763:		Line 763:
	Two more cases are refused '''unless Force is set''': a share marked '''immutable''', and a share that is used by, or was created by, a '''snapshot or replication schedule'''. A share nominated as a '''Cloud Container cache''' also needs Force, and its cloud containers should be removed first.		Two more cases are refused '''unless Force is set''': a share marked '''immutable''', and a share that is used by, or was created by, a '''snapshot or replication schedule'''. A share nominated as a '''Cloud Container cache''' also needs Force, and its cloud containers should be removed first.

	Where multi-admin approval ~~is configured~~, a delete raises an approval request instead of running, and the task reports how many of the required approvals have been met.		Where [[Security Configuration#Multi-admin Approvals\|multi-admin approval]] covers Network Share deletes, a delete raises an approval request instead of running, and the task reports how many of the required approvals have been met.

	== Related pages ==		== Related pages ==

Qadmin: Disable Oplocks: recommend it for shares used by NFS and SMB at once; link Multi-protocol File Locking

2026-09-24T03:11:57Z

Disable Oplocks: recommend it for shares used by NFS and SMB at once; link Multi-protocol File Locking

← Older revision		Revision as of 03:11, 24 September 2026
Line 206:		Line 206:
	\| '''Enable Auditing''' \|\| Records SMB file operations on this share. Auditing covers SMB/CIFS access only -- NFS activity is not audited -- and the log is written per system to {{Code\|1=/var/log/samba/audit.log}}, rotated at 1 GB and kept for five generations. Which operations are recorded, and the syslog facility and prefix used, come from {{Code\|1=/opt/osnexus/quantastor/conf/qs_smb_audit_defaults.conf}}; those values are read once at service start, so a change there needs a service restart. ''(The checkbox's tooltip names <code>quantastor.conf</code> instead; that is incorrect -- see QSTOR-12381.)''		\| '''Enable Auditing''' \|\| Records SMB file operations on this share. Auditing covers SMB/CIFS access only -- NFS activity is not audited -- and the log is written per system to {{Code\|1=/var/log/samba/audit.log}}, rotated at 1 GB and kept for five generations. Which operations are recorded, and the syslog facility and prefix used, come from {{Code\|1=/opt/osnexus/quantastor/conf/qs_smb_audit_defaults.conf}}; those values are read once at service start, so a change there needs a service restart. ''(The checkbox's tooltip names <code>quantastor.conf</code> instead; that is incorrect -- see QSTOR-12381.)''
	\|-		\|-
	\| '''Disable Oplocks''' \|\| Turns off opportunistic client-side locking. ~~Needed~~ for a few applications that mishandle oplock breaks, ~~at a cost in performance~~.		\| '''Disable Oplocks''' \|\| Turns off opportunistic client-side locking and SMB2/SMB3 leases, so SMB clients stop caching file data and byte-range locks. '''Tick it on any share that NFS and SMB clients use at the same time''': with oplocks on, NFS and SMB locks do not see each other and SMB clients can read stale data -- see [[Multi-protocol File Locking]]. Also needed for a few applications that mishandle oplock breaks. It costs SMB performance, most on small or lock-heavy I/O.
	\|-		\|-
	\| '''Ignore System ACLs''' \|\| Makes Samba ignore the POSIX ACLs on the filesystem, so the share's own permissions decide access. Use it when a Windows-managed ACL set and the underlying POSIX ACLs are fighting each other.		\| '''Ignore System ACLs''' \|\| Makes Samba ignore the POSIX ACLs on the filesystem, so the share's own permissions decide access. Use it when a Windows-managed ACL set and the underlying POSIX ACLs are fighting each other.
Line 769:		Line 769:
	* [[Storage Pools]] -- the pool a share is provisioned from		* [[Storage Pools]] -- the pool a share is provisioned from
	* [[NFS Configuration]] -- the NFS server implementations and system-wide NFS settings		* [[NFS Configuration]] -- the NFS server implementations and system-wide NFS settings
			* [[Multi-protocol File Locking]] -- locking on shares used by NFS and SMB clients at the same time
	* [[Active Directory Configuration]] -- joining a system to a domain so AD users and groups can be granted share access		* [[Active Directory Configuration]] -- joining a system to a domain so AD users and groups can be granted share access
	* [[Active Directory Leave]] -- leaving a domain		* [[Active Directory Leave]] -- leaving a domain

Qadmin: Correct the immutable-share deletion procedure in three places: clearing the auto-created hold is necessary but not sufficient, since the delete check counts snapshots rather than holds -- the snapshot must be deleted too, then --flags=force (QSTOR-12352)

2026-09-03T06:05:43Z

Correct the immutable-share deletion procedure in three places: clearing the auto-created hold is necessary but not sufficient, since the delete check counts snapshots rather than holds -- the snapshot must be deleted too, then --flags=force (QSTOR-12352)

← Older revision		Revision as of 06:05, 3 September 2026
Line 275:		Line 275:
	Anomaly Detection is independent of the '''Immutability / Write-Once-Read-Many (WORM) Support''' fieldset below and the two combine freely on one share. Both are served by the same per-pool filesystem monitor, which reads its configuration from {{Code\|1=/mnt/storage-pools/qs-<pool-id>/.monitor.conf}}; only the live share is watched, and its snapshots are not monitored in their own right. Turning detection on does not restrict deleting the share, unlike immutability.		Anomaly Detection is independent of the '''Immutability / Write-Once-Read-Many (WORM) Support''' fieldset below and the two combine freely on one share. Both are served by the same per-pool filesystem monitor, which reads its configuration from {{Code\|1=/mnt/storage-pools/qs-<pool-id>/.monitor.conf}}; only the live share is watched, and its snapshots are not monitored in their own right. Turning detection on does not restrict deleting the share, unlike immutability.

	'''Immutability / Write-Once-Read-Many (WORM) Support''' is create-time only -- the fieldset does not appear in the Modify dialog, so a share cannot be made immutable after the fact. '''None''' is the default; '''Immutable''' marks files in the share immutable, and '''Days of Immutability''' sets how long. A value of 0 means immutability never expires. An immutable share cannot be deleted without the force flag, and QuantaStor auto-creates a snapshot with a hold on it to prevent deletion~~, so clearing~~ that hold is ~~a prerequisite for removing~~ the share.		'''Immutability / Write-Once-Read-Many (WORM) Support''' is create-time only -- the fieldset does not appear in the Modify dialog, so a share cannot be made immutable after the fact. '''None''' is the default; '''Immutable''' marks files in the share immutable, and '''Days of Immutability''' sets how long. A value of 0 means immutability never expires. An immutable share cannot be deleted without the force flag, and QuantaStor auto-creates a snapshot with a hold on it to prevent deletion. '''Clearing that hold is necessary but not sufficient''' -- the delete then fails with <code>OSN_ERR_HAS_SNAPSHOTS</code>, because the check is on the snapshot count rather than on the hold. Removing an immutable share takes three steps: clear the hold, delete the snapshot, then delete the share with <code>--flags=force</code>.

	'''NFS Advanced Options''' has one field, '''Security Mode''', with three values:		'''NFS Advanced Options''' has one field, '''Security Mode''', with three values:
Line 579:		Line 579:
	* '''Tags are prefixed and there is only one.''' A tag you supply is prefixed with <code>QS-</code> if it does not start that way, an omitted tag becomes <code>QS-keep</code> (or <code>QS-</code> plus the schedule id for a scheduled snapshot), and a second hold on the same snapshot is refused.		* '''Tags are prefixed and there is only one.''' A tag you supply is prefixed with <code>QS-</code> if it does not start that way, an omitted tag becomes <code>QS-keep</code> (or <code>QS-</code> plus the schedule id for a scheduled snapshot), and a second hold on the same snapshot is refused.
	* '''The hold outlives the QuantaStor database.''' It is a hold on the underlying filesystem snapshot, so even a direct filesystem-level destroy is refused until the hold is released.		* '''The hold outlives the QuantaStor database.''' It is a hold on the underlying filesystem snapshot, so even a direct filesystem-level destroy is refused until the hold is released.
	* '''Immutable shares get one automatically.''' A share created with WORM/Immutable protection has a held snapshot auto-created specifically to block deletion~~; that~~ hold ~~has to~~ be ~~cleared~~ before the share can be removed.		* '''Immutable shares get one automatically.''' A share created with WORM/Immutable protection has a held snapshot auto-created specifically to block deletion. Clearing the hold is only the first step -- the snapshot itself must then be deleted before the share can be removed, because the delete check counts snapshots rather than holds.

	<code>[[QuantaStor CLI Command Reference#share-list\|qs share-list]] --include-snapshots=true --snapshots-with-holds-only=true</code> lists what is currently held.		<code>[[QuantaStor CLI Command Reference#share-list\|qs share-list]] --include-snapshots=true --snapshots-with-holds-only=true</code> lists what is currently held.
Line 756:		Line 756:
	\| The share '''belongs to a Global Namespace''' \|\| Remove it from the namespace first. The error names the namespace.		\| The share '''belongs to a Global Namespace''' \|\| Remove it from the namespace first. The error names the namespace.
	\|-		\|-
	\| The share, or one of its snapshots, '''has a hold''' on it \|\| Clear the hold. Immutable shares get an auto-created snapshot with a hold precisely to stop this.		\| The share, or one of its snapshots, '''has a hold''' on it \|\| Clear the hold, then delete the snapshot -- clearing the hold alone leaves the delete failing on the snapshot count. Immutable shares get an auto-created snapshot with a hold precisely to stop this.
	\|-		\|-
	\| The share's '''Storage Pool is not mounted or active''' \|\| Bring the pool online. If the pool no longer exists at all, the share's record is simply removed.		\| The share's '''Storage Pool is not mounted or active''' \|\| Bring the pool online. If the pool no longer exists at all, the share's record is simply removed.

Qadmin: Security Settings: document master's Anomaly Detection (renamed from Ransomware Detection) and the new Auto-tune Thresholds fieldset; per-subdir counting, alert behaviour, include-rule AND semantics (QSTOR-12352)

2026-09-03T05:44:03Z

Security Settings: document master's Anomaly Detection (renamed from Ransomware Detection) and the new Auto-tune Thresholds fieldset; per-subdir counting, alert behaviour, include-rule AND semantics (QSTOR-12352)

← Older revision		Revision as of 05:44, 3 September 2026
Line 225:		Line 225:
	=== Security Settings tab ===		=== Security Settings tab ===

	[[File:shares_create_security.png\|thumb\|right\|720px\|Security Settings, with ~~Ransomware~~ Detection enabled so the threshold and filtering fieldsets become editable.]]		[[File:shares_create_security.png\|thumb\|right\|720px\|Security Settings, with Anomaly Detection enabled so the auto-tune, threshold and filtering fieldsets become editable.]]

	Three unrelated groups of settings share this tab.		Three unrelated groups of settings share this tab.

	'''~~Ransomware~~ Detection''' watches ~~the rate of~~ file ~~modifications~~ and ~~deletions~~ on the share and ~~alerts~~ when ~~it exceeds~~ a threshold. The checkbox is off by default and the ~~two~~ fieldsets below stay disabled until it is ticked. It is not available on scale-out (CephFS) pools.		'''Anomaly Detection''' watches file modify and delete events on the share and raises an alert when the rate crosses a threshold you set -- the signature of ransomware encrypting a file tree in bulk, and equally of a runaway script or a mistaken recursive delete. The checkbox is off by default and the three fieldsets below it stay disabled until it is ticked. It is not available on scale-out (CephFS) pools, and the service refuses to enable it on RPM-based distributions (RedHat, Alma).

			Detection is per subdirectory. Every event is attributed to the directory it happened in, and each directory carries an hourly and a daily count. A '''modify''' counts distinct files touched, so a client rewriting the same file all afternoon contributes one; a '''delete''' counts every event, because a file can only be deleted once. The share's figure is the sum across its subdirectories, and the alert names the single busiest one -- which is the useful part of it, because that is where you start looking.

	{\| class="wikitable"		{\| class="wikitable"
	! Field !! Notes		! Field !! Notes
	\|-		\|-
	\| '''Hourly Modify Threshold''' \|\| ~~File modifies~~ per hour ~~that count as anomalous~~.		\| '''Hourly Modify Threshold''' \|\| Distinct files modified per hour, summed across the share's subdirectories. Must be greater than 0 -- a zero modify threshold would mean "alert on any activity at all", and the service rejects it.
	\|-		\|-
	\| '''Hourly Delete Threshold''' \|\| File deletes per hour. ~~May be left~~ at 0 to ~~leave~~ deletes ~~out of~~ detection entirely.		\| '''Hourly Delete Threshold''' \|\| File deletes per hour. Leave it at 0 to exclude deletes from detection entirely.
	\|-		\|-
	\| '''Daily Modify Threshold''' \|\| ~~File modifies~~ per day.		\| '''Daily Modify Threshold''' \|\| Distinct files modified per day. Also has to be greater than 0.
	\|-		\|-
	\| '''Daily Delete Threshold''' \|\| File deletes per day, and may likewise be left at 0.		\| '''Daily Delete Threshold''' \|\| File deletes per day, and may likewise be left at 0.
	\|}		\|}

	The tab's own header carries the warning that matters here: setting delete thresholds costs performance, because delete events then have to be tracked as well as modifies.		A threshold fires when the count '''reaches''' it rather than when it is exceeded, so a threshold of 15 alerts on the fifteenth file. The tab's own header carries the warning that matters here: setting delete thresholds costs performance, because delete events then have to be tracked as well as modifies.

			[[File:shares_security_autotune.png\|thumb\|right\|706px\|Ticking auto-tuning clears and disables the four manual thresholds and makes '''Auto-tune Duration''' editable.]]

			'''Auto-tune Thresholds''' exists because nobody knows what a share's normal traffic looks like before it has run for a while. Set the thresholds too low and every backup window pages someone; set them too high and the detector never fires. Tick '''Enable Anomaly Detection Parameter Auto-tuning''' and QuantaStor measures instead. '''Auto-tune Duration''' is a number of days -- 7 by default, 1 to 30 -- during which the filesystem monitor records the peak hourly and daily modify and delete counts the share actually sees. When the window closes, the four thresholds are set to twice those observed peaks and the share begins detecting against them.

			Two consequences are worth knowing before you use it:

			* '''No threshold alerts are raised for the share while it is auto-tuning.''' The window is a learning period and the share has no thresholds of its own during it -- the four manual fields read 0 and are disabled. Auto-tune a share that is already under attack and you teach it that the attack is normal.
			* '''Auto-tuning an idle share leaves a hair trigger.''' With no modify activity in the window there is no peak to double, so the thresholds fall back to built-in defaults of 3 modifies per hour and 10 per day. Choose a window that covers the share's real workload, month-end included.

			Ticking auto-tuning clears the four manual thresholds and disables them, since they are about to be derived; clearing it again puts back whatever you had typed. '''Auto-tune Duration''' is editable only once auto-tuning is ticked.

			In the Modify dialog, a share that is currently auto-tuning also shows a read-only '''Anomaly Auto-tune Ends''' date, and two rules apply to it:

			* '''Changing the duration adjusts the open window from when it started''' rather than restarting it, so cutting a 7-day window to 3 days on day 2 closes it on day 3. That is deliberate: an unrelated edit to a calibrating share re-sends the same duration when you click OK, and it has to be a no-op instead of buying another full week.
			* '''Clearing the auto-tuning checkbox ends the window immediately''' and the thresholds you type take effect from that point. You have to supply non-zero hourly and daily modify thresholds to do it, because a calibrating share has none of its own to fall back on, and the dialog refuses OK until you do.

			The CLI equivalents are <code>[[QuantaStor CLI Command Reference#share-create\|qs share-create]] --enable-anomaly-detection=true --anomaly-thresholds=hourlyModify:15,hourlyDelete:10,dailyModify:25,dailyDelete:20</code>, with <code>--auto-threshold-calibration-duration=<days></code> instead of the thresholds to auto-tune, and <code>[[QuantaStor CLI Command Reference#share-modify\|qs share-modify]] --cancel-auto-threshold-calibration=true</code> -- accompanied by <code>--anomaly-thresholds</code> -- to end a window early. Re-sending a duration adjusts the window in place, as in the dialog.

			'''Anomaly Detection Filtering''' narrows what is watched, using either include rules or exclude rules -- the two radio buttons are mutually exclusive and selecting one disables the other's panel. A rule is a substring, not a glob: <code>/subdirA/</code> or <code>.pdf</code>. An include rule limits detection to paths containing that substring; an exclude rule drops paths containing it. Filtering on delete events matches against the subdirectory path only and does not see the file name.

			'''Include rules combine with AND, not OR.''' A path has to contain '''every''' rule in the include list to be watched, so adding a second rule narrows the set rather than widening it: with <code>/keep/</code> and <code>/deep/</code> both listed, activity in <code>/keep/plain/</code> is ignored and only <code>/keep/deep/</code> is watched. Use a single include rule unless you specifically want that intersection. Exclude rules behave the way the list reads -- a path matching any one of them is dropped.

			'''What happens when a detection fires.''' The filesystem monitor records the event and the management service turns it into a '''Critical''' alert within a few minutes, named for the threshold that was crossed -- ''Hourly Modify Threshold / Possible Ransomware Detected'', and the daily and delete equivalents. The alert text carries the share's mount point, the busiest subdirectory and the count observed, and it goes out through [[Alert Manager]] like any other alert. Repeats of the same alert for the same share are suppressed for an hour, so a sustained burst raises one alert rather than one every few minutes.

			Detection alerts, and nothing more: it does not block the writes, disconnect the client or take a snapshot of its own. Recovery is yours to do, from the share's own [[#Snapshots\|snapshots]] -- so if a share is worth watching, give it a snapshot schedule as well, and consider a [[#Holds\|hold]] on the snapshots you most want kept, since a hold puts a snapshot out of reach of both the retention policy and an accidental delete.

	'''~~Ransomware Detection Filtering~~''' ~~narrows what is watched, using either include rules or exclude rules --~~ the two ~~radio buttons~~ are ~~mutually exclusive and selecting one disables~~ the ~~other's panel. A rule is a substring~~, ~~not a glob: <code>~~/~~subdirA~~/</~~code> or <code>~~.~~pdf</code>~~. ~~An include rule limits detection to paths containing that substring~~; ~~an exclude rule drops paths containing it~~. ~~Filtering~~ on ~~delete events matches against the subdirectory path only and~~ does not ~~see~~ the ~~file name~~.		Anomaly Detection is independent of the '''Immutability / Write-Once-Read-Many (WORM) Support''' fieldset below and the two combine freely on one share. Both are served by the same per-pool filesystem monitor, which reads its configuration from {{Code\|1=/mnt/storage-pools/qs-<pool-id>/.monitor.conf}}; only the live share is watched, and its snapshots are not monitored in their own right. Turning detection on does not restrict deleting the share, unlike immutability.

	'''Immutability / Write-Once-Read-Many (WORM) Support''' is create-time only -- the fieldset does not appear in the Modify dialog, so a share cannot be made immutable after the fact. '''None''' is the default; '''Immutable''' marks files in the share immutable, and '''Days of Immutability''' sets how long. A value of 0 means immutability never expires. An immutable share cannot be deleted without the force flag, and QuantaStor auto-creates a snapshot with a hold on it to prevent deletion, so clearing that hold is a prerequisite for removing the share.		'''Immutability / Write-Once-Read-Many (WORM) Support''' is create-time only -- the fieldset does not appear in the Modify dialog, so a share cannot be made immutable after the fact. '''None''' is the default; '''Immutable''' marks files in the share immutable, and '''Days of Immutability''' sets how long. A value of 0 means immutability never expires. An immutable share cannot be deleted without the force flag, and QuantaStor auto-creates a snapshot with a hold on it to prevent deletion, so clearing that hold is a prerequisite for removing the share.

Qadmin: Rewrite from the product against QuantaStor 6.9.0: all six Create/Modify tabs with defaults and enablement rules, NFS client access, SMB options, quotas/reservations, usage tracking, snapshots/holds, Global Namespaces, aliases/sub-shares/nested shares, templates, disable/delete semantics; corrected invented CLI arguments and context-menu items; 15 new screenshots (QSTOR-12352)

2026-09-03T04:50:26Z

Rewrite from the product against QuantaStor 6.9.0: all six Create/Modify tabs with defaults and enablement rules, NFS client access, SMB options, quotas/reservations, usage tracking, snapshots/holds, Global Namespaces, aliases/sub-shares/nested shares, templates, disable/delete semantics; corrected invented CLI arguments and context-menu items; 15 new screenshots (QSTOR-12352)

Show changes

Qadmin: Expand Quota Management: share-level, per-user, per-group, provisioning quotas; full CLI reference and alert thresholds

2026-06-17T03:45:28Z

Expand Quota Management: share-level, per-user, per-group, provisioning quotas; full CLI reference and alert thresholds

Show changes

Qadmin: Undo revision 25934 by Qadmin (talk)

2024-10-14T09:20:16Z

Undo revision 25934 by Qadmin (talk)

← Older revision		Revision as of 09:20, 14 October 2024
Line 1:		Line 1:
	[[~~index.php?title=~~Category:~~Admin guide~~]]		[[Category:admin_guide]]

	== Network Share (NAS) Management ==		== Network Share (NAS) Management ==
Line 22:		Line 22:
	QuantaStor ''network shares'' can be managed directly from the '''M'''icrosoft '''M'''anagement '''C'''onsole ('''MMC''') console Share Management section from Windows Server. This is often useful in heterogeneous environments where a combination of multiple different filers from multiple different vendors is being used.		QuantaStor ''network shares'' can be managed directly from the '''M'''icrosoft '''M'''anagement '''C'''onsole ('''MMC''') console Share Management section from Windows Server. This is often useful in heterogeneous environments where a combination of multiple different filers from multiple different vendors is being used.

	It is also possible to set this capability globally for a system by customizing the underling configuration file for '''S'''erver '''M'''essage '''B'''lock ('''SMB''') which is [[Enabling Global MMC Management\| outlined here]].		It is also possible to set this capability globally for a system by customizing the underling configuration file for '''S'''erver '''M'''essage '''B'''lock ('''SMB''') which is [[Enabling Global MMC Management \| outlined here]].

	===== Enabled =====		===== Enabled =====

Qadmin: Don't believe it's necessary to state that here.

2024-10-14T09:19:16Z

Don't believe it's necessary to state that here.

← Older revision		Revision as of 09:19, 14 October 2024
Line 1:		Line 1:
	[[Category:~~admin_guide~~]]		[[index.php?title=Category:Admin guide]]

	~~'''Please note, QutaStor version 4 is no longer supported.'''~~

	== Network Share (NAS) Management ==		== Network Share (NAS) Management ==
Line 24:		Line 22:
	QuantaStor ''network shares'' can be managed directly from the '''M'''icrosoft '''M'''anagement '''C'''onsole ('''MMC''') console Share Management section from Windows Server. This is often useful in heterogeneous environments where a combination of multiple different filers from multiple different vendors is being used.		QuantaStor ''network shares'' can be managed directly from the '''M'''icrosoft '''M'''anagement '''C'''onsole ('''MMC''') console Share Management section from Windows Server. This is often useful in heterogeneous environments where a combination of multiple different filers from multiple different vendors is being used.

	It is also possible to set this capability globally for a system by customizing the underling configuration file for '''S'''erver '''M'''essage '''B'''lock ('''SMB''') which is [[Enabling Global MMC Management \| outlined here]].		It is also possible to set this capability globally for a system by customizing the underling configuration file for '''S'''erver '''M'''essage '''B'''lock ('''SMB''') which is [[Enabling Global MMC Management\| outlined here]].

	===== Enabled =====		===== Enabled =====

Qadmin at 16:15, 12 December 2023

2023-12-12T16:15:14Z

← Older revision		Revision as of 16:15, 12 December 2023
Line 144:		Line 144:

	==== Leaving an Active Directory Domain ====		==== Leaving an Active Directory Domain ====
	To leave a domain first navigate to the ''Network Shares'' section and press the ''Active Directory Configuration'' button in the toolbar or by right-clicking in the "Network Shares" space and selecting "Active Directory Configuration" from the pop-up menu. Uncheck the checkbox to disable Active Directory integration and press OK.		[[Active Directory Leave\|To leave a domain]] first navigate to the ''Network Shares'' section and press the ''Active Directory Configuration'' button in the toolbar or by right-clicking in the "Network Shares" space and selecting "Active Directory Configuration" from the pop-up menu. Uncheck the checkbox to disable Active Directory integration and press OK.
	To remove the Computer entry from to AD domain controller one must specify the Domain Administrator username and password. After pressing ''OK'' the selected QuantaStor system will leave the domain.		To remove the Computer entry from to AD domain controller one must specify the Domain Administrator username and password. After pressing ''OK'' the selected QuantaStor system will leave the domain.

	===== Verifying Users Have CIFS/SMB Passwords =====		===== Verifying Users Have CIFS/SMB Passwords =====
	Older QuantaStor v2 & v3 systems were designed such that user accounts could not be implicitly used for SMB access, just management access. If a given user has the ''CIFS Ready'' property set to ''Password Change Required'' then the password for that user must be changed before the user account can be used to access SMB/CIFS shares. To do this simply select the user from the ''User & Groups'' section then select "Set Password" to change it via the change password dialog. Administrator users may change the password without having to supply the old password. After the password has been changed the property will update and will now show up as ''SMB/CIFS Ready''.		Older QuantaStor v2 & v3 systems were designed such that user accounts could not be implicitly used for SMB access, just management access. If a given user has the ''CIFS Ready'' property set to ''Password Change Required'' then the password for that user must be changed before the user account can be used to access SMB/CIFS shares. To do this simply select the user from the ''User & Groups'' section then select "Set Password" to change it via the change password dialog. Administrator users may change the password without having to supply the old password. After the password has been changed the property will update and will now show up as ''SMB/CIFS Ready''.