Possible Memory Leak in smbd
A week or so ago my FreeNAS server stopped responding and needed a forced reboot. I don't remember the exact error message but basically it was that no more bytes could be allocated to a process. All of my RAM and swap had been used up. Looking back at the Memory reports once the box came back up, yes "Wired" RAM went to 100% and a few days later swap did too. I didn't notice any performance degradation, though this is just a home file server and I wasn't paying a whole lot of attention to it until it stopped responding. Since the reboot I've been keeping closer tabs on memory usage and have notice that the smbd process is taking up more and more memory. Right now, it's up to 3.1GB. The only two changes I've made to the box over the last couple of weeks are upgrading from 11.0-U2 to 11.1-RELEASE and removing the box from an AD domain (basically removing all the config options from the Directory Service > Active Directory section and disabling it since it's not possible to remove the config entirely).
There is a thread over on the forums that describes just the problem I'm having, but I can't see where Morpheus187 opened a ticket, so I'm opening one of my own: https://forums.freenas.org/index.php?threads/samba-using-up-most-of-the-ram.61039
#17 Updated by Ian Cartwright over 2 years ago
I can't think of anything special I am doing. It's a typical home file server... Here's what is normally accessing FreeNAS via Samba at any time:
- Plex running on its own Linux VM (Ubuntu 16.04 LTS)
- Transmission running on its own Linux VM (Ubuntu 16.04 LTS)
- Crashplan running on a Mac (High Sierra)
- SecuritySpy running on that same Mac for camera captures
- The occasional file access from about 5 Mac and Windows clients
The only thing that comes even close to anything I might consider heavy usage is when Crashplan scans a few thousand files that it is backing up to the cloud for changes. And maybe Plex library updates, but it's been months or years since the last time I did a full library scan.
#18 Updated by Ian Cartwright over 2 years ago
Some more information:
The smbd process that is taking up all the memory is owned by a user that I only use for Crashplan and my camera capture files (the Mac names "spy" in the list above). Overnight there are about 70k "opened file/closed file" event pairs (140k log lines). This happens every night as Crashplan scans the files I am backing up to their cloud.
#19 Updated by Timur Bakeyev over 2 years ago
Andrew Walker seems found at least one cause of uncontrolled memory leakage of
Can you try the following configuration changes under Services->SMB:
1) Uncheck Unix Extensions
2) Add auxiliary parameter
wide links = yes
Can you, please, try this settings and check if that helps with your problem?
#21 Updated by Timur Bakeyev over 2 years ago
Since you mentioned Linux clients...
unix extensions (G) This boolean parameter controls whether Samba implements the CIFS UNIX extensions, as defined by HP. These extensions enable Samba to better serve UNIX CIFS clients by supporting features such as symbolic links, hard links, etc... These extensions require a similarly enabled client, and are of no current use to Windows clients. Note if this parameter is turned on, the wide links parameter will automatically be disabled. See the parameter allow insecure wide links if you wish to change this coupling between the two parameters. Default: unix extensions = yes
So, you may "lose" files on the shares that were actually symlinks to some other files. Please keep in mind, that Unix extensions work only with SMB 1.x protocol, which is widely disabled due security reasons on most deployments.
Alternatively, I think, you can just put it auxiliary parameters:
allow insecure wide links = yes wide links = yes
unix extensions on. We believe that issue is connected with the
wide links = no setting.
#23 Updated by Ian Cartwright over 2 years ago
It's been 4 days an none of the smbd processes has grown to more than 190M according to top. The process at 190M is owned by the Crashplan users (this is the process that would grow to multiple GB before). The other smbd processes are around 150M.
The config changes seem to have done the trick.