STATUS_TOO_MANY_NODES (0xC000020E) – SMB node limit hit

1. Stale SMB sessions eating all available nodes

What's actually happening here is that Windows SMB has a hard ceiling on how many simultaneous node objects the transport layer can track. On Windows Server 2019/2022, the default is often 256 or 512, depending on the SKU and whether SMB Multichannel is active. Each client connection—even if idle—reserves one node. If you've got a fleet of machines mounting and unmounting network drives, or a script that net uses to the same server repeatedly without cleanup, those node objects pile up. You get 0xC000020E when the transport says “I literally cannot allocate another node.”

The fix: purge dead sessions and reset the stack

1. Check current node count – run this PowerShell on the file server (the one that can't accept connections):
   

   Get-SmbSession | Measure-Object | Select-Object -ExpandProperty Count

   
   If it's above 250 on a default install, you've hit the ceiling.
2. Force-close stale sessions – don't be polite. Run:
   

   Get-SmbSession | Where-Object {$_.IdleTime -gt [TimeSpan]::FromHours(4)} | Close-SmbSession -Force

   
   This kills sessions that have been idle longer than 4 hours. The reason this works is that many stale sessions are from disconnected client drives that never properly released their node.
3. Restart the SMB client on the connecting machine – sometimes the server side is fine, but a specific client has exhausted its own node cache. On the client that gets the error, run:
   

   net stop mrxsmb && net start mrxsmb

   
   This flushes the local node table. You'll lose active connections temporarily, but it's often the only way to clear a corrupted state.

Real-world trigger: A backup agent that mounts a share for each job and never unmounts. After 256 backup jobs, every new mount attempt fails with 0xC000020E.

2. SMB Multichannel node explosion

SMB Multichannel is great for performance—it uses multiple network paths to a single server. But each path counts as a separate node in the transport layer. If you have a two-NIC client connecting to a four-NIC server over two subnets, that's potentially 8 nodes per session. With 32 concurrent sessions, you're already at 256 nodes. The error pops up because the node table fills up even though your actual session count looks low.

The fix: limit Multichannel or raise the node cap

1. Disable Multichannel for problematic clients – on the server, set:
   

   Set-SmbServerConfiguration -EnableMultiChannel $false -Force

   
   This is a hammer. Only do it if you're sure the error correlates with high Multichannel usage. The downside is losing aggregate bandwidth.
2. Raise the MaxWorkItems parameter – this is the actual registry key that controls the node limit. On the server:
   

   New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name "MaxWorkItems" -Value 1024 -PropertyType DWORD -Force
   Restart-Service LanmanServer

   
   The default is usually 256. Jump to 1024 if you have memory to spare (each workitem eats about 2KB). The reason this works is that MaxWorkItems directly controls the size of the internal node table that SMB uses to track connections.

Real-world trigger: A file server with four NICs in a team plus Multichannel enabled. Connecting 20 clients over multiple paths burns through 256 nodes in minutes.

3. Cluster (failover) node limit hit

This one's specific to Windows Failover Clustering. If you're running a clustered file server and see 0xC000020E, the cluster's own node-to-node connections are consuming the transport nodes. Each cluster heartbeat between nodes uses a node object. When you add new nodes or witness shares, the cluster service may fail to allocate transport nodes.

The fix: increase cluster transport resources

1. Validate cluster health – run:
   

   Get-ClusterResource | Where-Object {$_.State -eq 'Failed'}

   
   Look for any resource in a failed state that might be holding a node object open.
2. Increase the cluster's MaxNodes registry value – this isn't documented well, but it exists under:
   

   HKLM:\Cluster\Parameters\MaxNodes

   
   Set it to a DWORD of 512 or 1024. You'll need to restart the Cluster service (which will fail over resources). Only do this during maintenance.
3. Reduce heartbeat frequency – if you have many nodes, lower the rate so node objects are recycled slower:
   

   (Get-Cluster).SameSubnetDelay = 2000
   (Get-Cluster).CrossSubnetDelay = 4000

   
   This gives the transport more time to reuse node slots between heartbeats.

Real-world trigger: A 4-node Hyper-V cluster with 6 CSV volumes and a file server role. During a rolling patch cycle, nodes fail back and the cluster hits the node limit.

Quick-reference summary table