Weird smbd crashes. Is Ventura unusable as a file server?

I know you cool kids all do NAS and cloud storage nowadays, but I’m old school. Since forever I’ve had a server in my closet, running basic services such as local file sharing, a couple of Linux VM’s for webservers and VPN, torrent client, Homebridge etc.


My trusty server, a Mac Mini 2014 with only 4 Gb of RAM has started to show its age, not least as it cannot be upgraded past Monterey. When I got hold of a discarded laptop with an Intel Core i5 Gen 8 and 16 Gb of memory, I figured it was time for an upgrade.


However, now I’ve almost given up, as the SMB server crashes constantly!


You see, I have some external USB3 disks (APFS formatted) connected to the computer and I was hoping to do some file sharing to my other computers in my house. I can connect, mount and browse without issues. However, when playing a video file and jumping around a little in the timeline, suddenly the player just stops and jump to the end of the file.


To figure out if it was client or server issue, I looked at the console messages. Pretty quickly I realized that it must be the server. In the server console I see a whole bunch of smb errors seconds before and after the video stops playing. Playing files from the local SSD does not seem to produce crashes, at least not in my testing.


The smbd process restarts, and while I can (most often) restart the video, the interruptions are not acceptable. I poked around and followed the breadcrumbs in a vain attempt to figure it out. But just about here is where it becomes pretty obvious that only my mother really thinks I’m a hacker. Anything that uses hexadecimals is lost on me, although I have to stress how much a revere the wizards who dare to tread those magical and mystical lands. Sorry, I got a little bit off topic.


In the server console log (below), after filtering for “smb”, you can follow how the daemon (PID: 1788) is pronounced dead. It’s also the usual stew of messages from wherever, along with what appears to be quite esoteric error messages, as I can’t find any mentions of them anywhere else on the interwebs.


CONSOLE LOGS:

https://pastebin.com/MCDJGxrq


The crash logs it so gracefully created can be found below. And yes, there is one for every crash, but I included the one.


CRASH REPORT:

https://pastebin.com/8AmhFvbE


So, I guess my question is: what should I do? I don’t want to bore you with what I already have tried. Even before I narrowed it down to an smbd issue. So much snake oil on the internet. I’ve tried turning file sharing on and off. Someone said there had to be a restart while off. So I tried that too. I’ve tried disabling IPv6. I’ve messed with settings to disable SMBv1 and force SMBv3. Until someone said it should be vice versa. Replaced USB cables, although the files play fine locally. I’ve trashed plists and interfaces. Started over. Reinstalled. Etcetera. And now I’m at a loss.


I should also add that the external disk(s) works without issues connected to my old server, running Monterey.


I can see that com.apple.root.default-qos is mentioned as an offender. But why, and what can I do about it?


Can somebody make sense of the logs? Anyone?

Posted on May 27, 2023 12:07 PM

Reply

Similar questions

14 replies

Apr 21, 2024 08:06 AM in response to vinzsyd

I'm trying right now an applescript that run in the background. What it does ? It unblock the SMB process from the firewall.


do shell script "echo 'YOUR PASSWORD HERE' | sudo -S  /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/sbin/smbd"


Replace 'YOUR PASSWORD HERE' with your admin password, inside the ' '.

It seems to work since a fews days.


Apr 21, 2024 10:23 AM in response to Microtrash

Microtrash wrote:

I'm trying right now an applescript that run in the background. What it does ? It unblock the SMB process from the firewall.

do shell script "echo 'YOUR PASSWORD HERE' | sudo -S  /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/sbin/smbd"

Replace 'YOUR PASSWORD HERE' with your admin password, inside the ' '.
It seems to work since a fews days.

Why not just turn the Application Firewall off completely. It isn't doing anything useful.

Apr 22, 2024 06:40 PM in response to Microtrash

Microtrash wrote:

do shell script "echo 'YOUR PASSWORD HERE' | sudo -S  /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/sbin/smbd"

Replace 'YOUR PASSWORD HERE' with your admin password, inside the ' '.
It seems to work since a fews days.

FYI, You should never hard code a password into any script or app. I don't know how to do this properly on macOS.

Apr 22, 2024 09:04 PM in response to Microtrash

Microtrash wrote:

True. Security wise, it's usually a no. But when you have non-administrator user in front of the computer, you don't want to give them the admin password, and you don't want them to call you every day to run this script. I know there is a way to refer to a .txt file for the password, but I didn't get it to work.

How about a cron job instead (or maybe there is a better macOS option)?


Or you can perhaps add a file to "/etc/sudoers.d/" to allow the user root access just to use that one specific command & option "/usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp". Do not edit the "sudoers" file itself, but create a new file in "/etc/sudoers.d" to only give that user access to that very specific line. By including the "--unblockapp" option, it should prevent that user from using any other option for that "socketfilterfw" utility. You may need to include the "/usr/sbin/smbd" portion as well (It has been a long time since I added any custom entries). You would need to use the "visudo" command to create the new file which will give the file proper permissions & perform a syntax check as well (my example will create a new file "smb_firewall_unblockapp" file).

EDITOR=nano  sudo  visudo  -f  /etc/sudoers.d/01_smb_firewall_unblockapp


You would need to add the proper line to that file to give access to that particular user(s). Something like:

<user-name>  ALL=(ALL:ALL)  /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/sbin/smbd


This version should cause the "sudo" command to prompt for the Standard user's password. If you don't want the password prompt, or if the password prompt causes a problem, then you can use the "NOPASSWD:" tag so the user will not be prompted for any password:

<user-name>  ALL=(ALL:ALL)  NOPASSWD:/usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/sbin/smbd


Of course you must replace "<user-name>" with the correct name of the user you want to allow to use that command. For me that would be "hwtech".


I don't have a system to use to test the sample line for the "sudoers.d" option, nor do I currently have access to the system where I customized "sudoers" to confirm how I did it exactly, but I believe what I have presented is correct or at least gives you a starting point.


I would suggest putting including a comment line beginning with "#" as well to explain exactly what this exception is for so someone finding it later on will know whether it should be left alone or removed.


This "sudoers" option could cause alerts with some third party security monitoring software and may not be appropriate for use in some organizations.


You must be extremely careful when creating any customized entries for "sudoers" since you may open a whole lot of possible vulnerabilities that may not be immediately evident. Giving very specific commands & options should limit unintended consequences as long as the upgraded user privilege is for a binary command and not a script. And just another reminder.....do not modify the actual "sudoers" file, just add a new file to "/etc/sudoers.d/" folder.

Apr 23, 2024 05:52 PM in response to j_lundqvist

j_lundqvist wrote:


Microtrash wrote:

[...] the smbd thread keep crashing since ventura.
My workaround was to revert to Monterey, but what I'd be interested to know is if it works again on Sonoma. I didn't feel like going through all this again when it was released.

Im on Sonoma and its happening :( never tested it in Monterey but good to know it works there.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Weird smbd crashes. Is Ventura unusable as a file server?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.