Plan an all-node detachment before increasing a shared disk's maxShares

Source facts

An Azure shared disk’s maxShares value sets the upper bound on simultaneous sharing nodes. The value can be changed only when the disk is detached from every node, and the supported maximum depends on disk type and, for some types, disk size. Shared disks require a cluster manager to coordinate communication and write locking; they are shared block devices, not a native managed SMB or NFS filesystem. Microsoft Learn.

Applicability

Use this review when adding nodes to an existing cluster could exceed its configured attachment ceiling. Inventory the actual attachments, disk type, and supported maximum instead of assuming that current cluster membership defines the setting.

DSE recommendation

Compare the intended node count with maxShares before committing to a cluster expansion window. Have the cluster and storage owners determine whether the planned nodes fit the existing limit. If the limit must change, prepare an authorized all-node detachment and service-recovery sequence using the application’s supported procedure. Keep the proposed setting within the source’s disk-specific limits and preserve a clear mapping between the shared resource and every consumer.

Verification

After the approved change and reattachment, inspect maxShares and the actual node attachments. Test the intended clustered workload and its ownership behavior before declaring the expansion complete. Record any node that cannot attach or participate as unresolved. Do not use concurrent ordinary filesystem access as a substitute for the required cluster coordination, and do not assume raising an attachment ceiling alone establishes a supported application topology.

Official references

Microsoft Learn: Share an Azure managed disk across VMs. Source reviewed September 9, 2026.