This error means your server's share list is full
I know this error is infuriating — you're trying to add a new network share, and Windows just slams the door with 0X00000849 (or the human-friendly NERR_TooManyItems). It's especially common on file servers that have been running for years, accumulating shares from old projects, backups, or automated scripts. Let me save you the headache.
The fast fix: remove unused shares
Open an elevated Command Prompt (right-click cmd, Run as Administrator) and run:
net shareThat lists every share on the box. Look for shares you don't need — those old ProjectX_Backup or TempShare_2022 entries. Delete them with:
net share ShareName /deleteReplace ShareName with the actual name. Do this until you've freed up at least 5-10 slots. Then try adding your new share again. Nine times out of ten, that's it.
If that's not enough: bump the registry limit
Windows Server (2012 through 2022) has a hard cap of 256 shares by default. Yes, that includes hidden shares like ADMIN$, C$, and IPC$. Those count against the limit too. You can raise it, but don't go crazy — the server has to manage them all.
- Open Regedit as Administrator.
- Go to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters - Create a new DWORD (32-bit) named
MaxSharesif it doesn't exist. - Set the value to 512 (decimal) — that's twice the default. I've seen people try 1024, but that can cause memory pressure on busy servers.
- Reboot the server. Or restart the Server service:
net stop lanmanserver && net start lanmanserver
Warning: Restarting the Server service disconnects all active SMB sessions. Users will lose access to their mapped drives briefly. Do this during a maintenance window.
Why does this happen?
The Server service (lanmanserver) allocates a fixed-size buffer for tracking share entries. Once you hit that ceiling — 256 by default — any new share request returns NERR_TooManyItems. This isn't a bug; it's a design choice from the NT era to prevent runaway memory use. But modern servers with lots of RAM can handle more.
The most common trigger I see: automated backup software (like Veeam or ShadowProtect) that creates temporary shares for mounting volumes, then never cleans them up properly. Over a few months, those temporary shares pile up and silently hit the limit.
Less common variations
Sometimes you'll see this error not from adding a share, but from trying to enumerate shares via WMI or PowerShell. The error wording might be slightly different:
“Requested addition of items exceeds the maximum allowed”— same root cause.“The server cannot allocate enough memory for the share”— misleading, because it's the count, not actual memory pressure.“NERR_TooManyItems”in event logs under System with sourcesrv— this is the giveaway.
If you see this on a client OS like Windows 10 or 11 (unlikely, but possible with file sharing enabled), the limit is lower — usually 50 shares. Cleanup is your only option there; the registry tweak doesn't work on desktop editions.
Prevention: keep the share list lean
Set a quarterly reminder to audit your shares. Run net share and look for anything older than 90 days that's not documented. Better yet, use a PowerShell script to export all shares with creation dates:
Get-SmbShare | Select-Object Name, Path, Description | Export-Csv C:\shares_audit.csvIf you're using backup software, check its settings for “remove temporary shares after job completes” — that option exists in most enterprise tools. Flip it on.
And if you regularly spin up shares for short-term projects, consider using symbolic links or DFS namespaces instead. Those don't count against the share limit.
One last opinionated tip: don't set MaxShares above 512 unless you've tested it under load. I've seen a Windows Server 2022 box with 800 shares start to lag on browse requests. The SMB protocol wasn't built for that many endpoints on a single server. Keep it sane.
Now go clear out those old shares and get back to work.