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

> Can an Azure shared disk's attachment ceiling be increased while existing cluster nodes still use it?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:30:58+00:00
- Modified: 2026-09-10T00:35:07+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

Can an Azure shared disk's attachment ceiling be increased while existing cluster nodes still use it?

## Potentially affected

Clusters using supported Azure shared managed disks and planning a change to their maximum simultaneous attachments.

## DSE recommendation

Compare the intended node count with maxShares before committing to a cluster expansion window.

## Article

## 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](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-shared).

## 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](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-shared). Source reviewed September 9, 2026.

## Primary reference

- Name: Share an Azure managed disk across VMs - Azure Virtual Machines | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-machines/disks-shared
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Plan an all-node detachment before increasing a shared disk's maxShares,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.