Debugging and Fixing CIFS_MOUNT Failed with Return Code -12 (NT_STATUS_INSUFF_SERVER_RESOURCES) in Samba Server Environments


3 views

During routine operations with RHEL 5.9 running smbd 3.0.33, we encountered a particularly nasty intermittent mounting issue where clients (using mount.cifs 5.2) would randomly fail with:

mount error(12): Cannot allocate memory
kernel: CIFS VFS: cifs_mount failed w/return code = -12

What made this especially perplexing was that only one client machine exhibited the problem while others worked flawlessly, despite identical configurations.

First, we enabled comprehensive logging on both client and server:

# Client side debugging
echo 1 > /proc/fs/cifs/cifsFYI

# Server side logging (smb.conf)
log level = 3

The critical clues emerged from the logs:

# Client debug output
Mapping smb error code 0xc0000205 to POSIX err -12

# Server log
error packet at smbd/reply.c(514) cmd=117 (SMBtconX) 
NT_STATUS_INSUFF_SERVER_RESOURCES

Running smbstatus -S | grep [serverIP] | wc -l revealed the shocking truth - 2048 active connections, mostly IPC$ shares. Samba creates one IPC$ share per user connection rather than per client, and these weren't being properly cleaned up.

Adding this to smb.conf immediately resolved the issue:

[IPC$]
   hosts deny = 0.0.0.0/0
   # Alternatively for more granular control:
   # hosts allow = 127.0.0.1
   # hosts deny = ALL

For enterprise environments, consider these smb.conf tweaks:

[global]
   # Limit concurrent connections per share
   max connections = 1000
   
   # Adjust IPC$ timeout (seconds)
   deadtime = 15
   
   # Cleanup idle connections
   keepalive = 300

Here's a bash script to monitor share counts and alert when approaching limits:

#!/bin/bash
THRESHOLD=1900
CURRENT=$(smbstatus -S | grep -c "[serverIP]")

if [ $CURRENT -ge $THRESHOLD ]; then
   logger "Samba Warning: $CURRENT active shares (threshold $THRESHOLD)"
   # Add notification logic here
fi

The IPC$ share in Samba serves multiple purposes including:

  • Anonymous share enumeration
  • Remote administration functions
  • SPOOLSS printing services

By restricting access to IPC$, we prevent the share explosion while maintaining essential functionality through authenticated regular shares.


While working with a RHEL 5.9 Samba server (smbd 3.0.33) and modern CIFS clients (mount.cifs 5.2), I encountered a particularly vexing issue where one specific client would randomly fail to mount shares with:

mount error(12): Cannot allocate memory
CIFS VFS: cifs_mount failed w/return code = -12

The kernel logs revealed the underlying SMB error mapping:

Mapping smb error code 0xc0000205 to POSIX err -12

Server-side Samba logs (with log level = 3) showed the critical clue:

error packet at smbd/reply.c(514) cmd=117 (SMBtconX) 
NT_STATUS_INSUFF_SERVER_RESOURCES

Running smbstatus -S | grep [serverIP] | wc -l returned 2048 connections - exactly the default maximum share limit. Further investigation showed thousands of orphaned IPC$ connections.

Samba creates an IPC$ share for each user connection to facilitate:

  • Anonymous share browsing
  • Remote administration
  • Inter-process communication

In my case, these connections weren't being properly cleaned up, eventually exhausting available resources.

The most straightforward fix was to block IPC$ access in smb.conf:

[IPC$]
   hosts deny = 0.0.0.0/0
   # Optionally add specific exceptions:
   # hosts allow = 192.168.1.100 192.168.1.101

Alternative approaches worth considering:

# Increase connection limits (not recommended long-term)
max smbd processes = 4096

# Set idle connection timeout (in seconds)
deadtime = 15

For production environments, consider implementing these monitoring solutions:

#!/bin/bash
# Samba connection monitor script
THRESHOLD=1500
CURRENT=$(smbstatus -S | wc -l)

if [ "$CURRENT" -gt "$THRESHOLD" ]; then
   logger "Samba connection threshold exceeded: $CURRENT"
   # Add automatic cleanup logic if needed
fi

This issue highlights several important Samba administration concepts:

  • The relationship between SMB protocol errors and POSIX error codes
  • How client-side errors may originate from server resource limitations
  • The importance of proper connection cleanup in long-running services