Unbounded SMB Connection Accumulation Causing NAS System Crash

[ingmar_ehrig 1]

Summary

Emby Server running on NVIDIA Shield TV Pro (2019) accumulates SMB/CIFS connections to a network-attached SMB share over time, without releasing them. Once the connection count reaches several hundred, the NAS (WD My Cloud EX2 Ultra) becomes fully unresponsive due to load, requiring a hard power cycle to recover. This has caused two separate NAS-side crashes within roughly one hour of normal media playback usage and several more since I installed emby Server on my ShieldTV.

Note: I have another emby server running on my MyCloudEX2 for years running without any single problem. I just wanted to switch to a newer .NET System instead of mono.

Environment

• Emby Server version: 4.9.5.0
• Device: NVIDIA Shield TV Pro (2019), Tegra X1+
• Android-Version: 11
• Build-ID: RQ1A.210105.003.7825230_4387.0822
• NAS / SMB Server: WD MyCloud EX2 Ultra, MyCloud OS 5, Samba (smbd)
• Network: Gigabit Ethernet, local network only (no remote access)
• Library storage: SMB share (smb://<NAS-IP>/...), accessed via mapped/attached network storage in Emby

Steps to Reproduce

• Set up Emby Server on Shield TV with library folders pointing to an SMB share on a separate NAS.
• Use the server normally over an extended period (library scans, browsing, video playback) — no unusual or heavy load, single concurrent stream.
• Periodically check the number of active SMB connections from the Shield's IP address on the NAS side:

            netstat -an | grep :445 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn

 

• Observe that the connection count from the Shield's IP grows continuously over hours/days, rather than staying stable at a low number (1-5).

Observed Behavior

• At the time of the crash, 393 out of 397 total SMB connections on the NAS originated from the single Shield device running Emby Server.
• This coincided with the NAS Linux kernel load average spiking to over 400 (on a 2-core system), with dozens of smbd worker processes stuck in uninterruptible sleep (D state), waiting on I/O.
• The NAS's web dashboard, and eventually most background services (Apache/httpd, nasAdmin, monit), became unresponsive. SSH access remained marginally functional but was severely lagged.
• Restarting Emby Server on the Shield (via its own web interface restart function, without touching the NAS) immediately dropped the SMB connection count from 393 to 0, and the NAS load began recovering.
• This is reproducible: the connection count was independently confirmed via netstat before and after the Emby restart, isolating Emby Server (and not any other NAS-side process) as the source of the accumulated connections.

Expected Behavior

Emby Server's SMB client should reuse or properly close SMB connections/sessions after file operations (metadata reads, thumbnail loads, playback) complete, keeping the connection count to the NAS low and stable regardless of how long the server has been running or how many files have been scanned/played.

Additional Notes

• No equivalent SMB connection accumulation was observed when running Emby Server directly on the NAS itself (WD My Cloud "Emby Server" app, Mono-based build) accessing local storage — this issue appears specific to the Android TV client/server's SMB implementation when accessing a remote SMB share.
• There is no user-facing setting within Emby Server for Android TV to control SMB connection pooling, reuse, timeout, or maximum concurrent connections.
• This is a serious issue beyond cosmetic/performance concerns: it results in total NAS unavailability requiring a hard power cycle, affecting all other devices/services relying on that NAS (other Emby libraries, other network clients), not just Emby itself.

Suggested root cause area

Possibly related to how the Android TV media probe / file streaming layer (MediaProbeManager, ffprobe file access via local loopback Items/File proxying seen in server logs) or the underlying SMB/CIFS client library opens a new connection/session per file access request instead of reusing an existing pooled connection to the same share/host.

 

Best regards

Ingmar

embyserver-63921908969.txt embyserver-63921916800.txt embyserver-63921922586.txt

[Luke 42864]

Hi, the smb library we’re embedding is probably opening a new connection per file access, however they shouldn’t be left open.