I use a network share (NAS) with my Mac. I have done so for many years. I feel the need to specify that there is nothing wrong with it. It has worked fine on older Macs for years (and still works fine with them). It works fine on my Windows computer.
But on macOS 15 at least, it will (eventually) cause my system to lock up and make me force restart. Specifically, whenever a process on my Mac (client) cannot access the share (server), it locks up, forever.
I have a screenshot of the sample of an process stuck on this:
As you can see, this process gets stuck in a kernel call waiting for information from the network share. This will be stuck forever, there is no timeout for this. That's the problem.
You may also notice the name of the process I sampled, it's an Open and Save panel. Since every macOS app needs to use this to save documents, this will cause every app to lock up if you try to open or save a file. Any app that already has a file open from the share will also lock up. This will also happen to Finder itself, because it also tries to access the connected network share(s). This will happen to any terminal process where you try to force eject/unmount the inaccessible network share. (Also note that this is a screenshot, I couldn't save it from Activity Monitor because the OSP process for Activity Monitor froze as well)
Because this function call is in the kernel, it is impossible to force quit any of these processes. They will remain stuck, open, unresponsive until you restart. Speaking of, you cannot use the Restart menu item, as that will just hang trying to log you out, in this situation you must use
in the terminal.
Now, I'm sure some people will jump in, and try to say that this is somehow my fault, or at least not Apple's. First off, network connections are inherently unreliable. They fail, you get disconnected, etc. Wi-Fi connections drop, cables get unplugged, nodes along the network restart or go offline. My router, for example, occasionally restarts overnight with software updates. Sometimes the NAS needs a reboot, or just gets disconnected. On my Windows computer, or older Macs running older versions of macOS, this is no big deal. Because, even if they try to access the disconnected SMB share, they will eventually time out. For some reason, macOS 15 does not do this. There is no timeout. It will get stuck forever.
I don't understand why Apple programmed a network function that doesn't have a timeout. Even filesystem operations have a timeout because connection problems can happen. This is basic network programming. Would it be acceptable for a bad web server to be able to lock up your computer (or Safari at least) by just not responding? No, obviously.
This bug isn't just unacceptable or dumb or weird, it's INSANE.
Bonus: This happens on iOS too (at least to a lesser extent, because there does seem to be a timeout). Sometimes I connect to my NAS via the Files app, and if I end up on cellular and try to open the Files app, it will become completely unresponsive, apparently in an attempt to connect to a now inaccessible share. As I said, this does appear to have some kind of timeout as it will respond eventually, but one must wonder why the OS/UI becomes unresponsive. Apple themselves recommends that developers NEVER block the main UI thread. Why are they doing it themselves?
But on macOS 15 at least, it will (eventually) cause my system to lock up and make me force restart. Specifically, whenever a process on my Mac (client) cannot access the share (server), it locks up, forever.
I have a screenshot of the sample of an process stuck on this:
As you can see, this process gets stuck in a kernel call waiting for information from the network share. This will be stuck forever, there is no timeout for this. That's the problem.
You may also notice the name of the process I sampled, it's an Open and Save panel. Since every macOS app needs to use this to save documents, this will cause every app to lock up if you try to open or save a file. Any app that already has a file open from the share will also lock up. This will also happen to Finder itself, because it also tries to access the connected network share(s). This will happen to any terminal process where you try to force eject/unmount the inaccessible network share. (Also note that this is a screenshot, I couldn't save it from Activity Monitor because the OSP process for Activity Monitor froze as well)
Because this function call is in the kernel, it is impossible to force quit any of these processes. They will remain stuck, open, unresponsive until you restart. Speaking of, you cannot use the Restart menu item, as that will just hang trying to log you out, in this situation you must use
Code:
sudo shutdown -r nowNow, I'm sure some people will jump in, and try to say that this is somehow my fault, or at least not Apple's. First off, network connections are inherently unreliable. They fail, you get disconnected, etc. Wi-Fi connections drop, cables get unplugged, nodes along the network restart or go offline. My router, for example, occasionally restarts overnight with software updates. Sometimes the NAS needs a reboot, or just gets disconnected. On my Windows computer, or older Macs running older versions of macOS, this is no big deal. Because, even if they try to access the disconnected SMB share, they will eventually time out. For some reason, macOS 15 does not do this. There is no timeout. It will get stuck forever.
I don't understand why Apple programmed a network function that doesn't have a timeout. Even filesystem operations have a timeout because connection problems can happen. This is basic network programming. Would it be acceptable for a bad web server to be able to lock up your computer (or Safari at least) by just not responding? No, obviously.
This bug isn't just unacceptable or dumb or weird, it's INSANE.
Bonus: This happens on iOS too (at least to a lesser extent, because there does seem to be a timeout). Sometimes I connect to my NAS via the Files app, and if I end up on cellular and try to open the Files app, it will become completely unresponsive, apparently in an attempt to connect to a now inaccessible share. As I said, this does appear to have some kind of timeout as it will respond eventually, but one must wonder why the OS/UI becomes unresponsive. Apple themselves recommends that developers NEVER block the main UI thread. Why are they doing it themselves?