SMB + Adobe = kernel panics

New Contributor II

I've been having an issue on a number of the Macs here at the office. Usually when using an Adobe app and often when saving a document directly on the server, a user's computer will all of a sudden kernel panic and restart. In analyzing the backtrace, the only common element in every case has been 3.0.1.

Our environment:
- All our Macs are running 10.10.3.
- We have an NetApp appliance hosting files that users connect to using SMB. Most users connect to the share at the beginning of the day, and stay connected for the whole day.
- The issue only seems to effect users that are in Adobe CC products all or most of the day.

On some user's computers, moving them to cifs to force SMB 1 has reduced or completely fixed the issue, but not on all.

There's not a ton of documentation on the issue online that I've been able to find, but one user on Apple's support forums postulates that it has something to do with apps that generate temporary files, like Adobe's suite, Microsoft's office suite, and Preview.

Has anyone else encountered this type of issue before? I'm pretty stuck as to what to do at this point.


Valued Contributor

The response we got from Adobe is "stop saving directly to network storage, because we don't support doing that." It's a terrible response, but so far it's been the only thing resembling a solution that we've received. The problem has existed since at least CS5, maybe even prior to that.

Not applicable

I've also got CS6, CC and CC2014 users accessing a NetApp share - connecting via cifs:// does seem to help, but still nowhere near as good as afp://on my old Xserve.

One thing that I've noticed is there are many more problems if the user creates a new folder from within an Adobe app on the share - I don't admin that server so I can't do much with permissions and inherited access control lists. I advise my folks to only ever create any new folders from the Finder, but opening and saving files seems to work.

What kind of user accounts? Any ACLs on the share and are any of them nested groups? What differences, if any, exist between the folks that using cifs:// helps versus the problem still existing?

Valued Contributor

It's pretty much always been Adobe's response:

Contributor III

@ihalvorson We had problems the same to what you are experiencing, the cause was the naming of the share on the server if the share was - smb://server/home the issue occurred, but if the share was - smb://server/Home the issue disappeared. One thing we did note was that files could be dropped into the share without any issue and also opened from the share but just not changed in any way or saved.

This was having the users "home" share , on the server with the same name and case as the unix "home" on the local computer, renaming the share with an upper case "H" in our setup resolved the issue.

New Contributor

We are having the same issue at our company. Many of our creative artists/designers are experiencing this particularly in Illustrator. I have re-staged a machine having the problem, which helped but it still occurs, but not as frequent. I opened a support case with Apple Enterprise support, and got this response:

>>I would recommend to test by disabling FIDs. To do this we simply disable this setting in /etc/nsmb.conf using >>file_ids_off=yes:
>>sudo echo "[default]" >> /etc/nsmb.conf
>>sudo echo "file_ids_off=yes" >> /etc/nsmb.conf
>>A reboot will be needed after this change.

Since this nsmb.conf file didn't exist, I created it in Composer, built a policy to add it to machines and scoped it in the JSS to the people having the problem. This, too, seemed to help but not cure.

@dmw3: your note in renaming the directory with a capital H, did that completely cure the issue? Thanks.

New Contributor II

@dmw3 When you mention the capital H solution, are you referring to changing the name of the share on the server, or the name of the share when connecting from the client Mac? As in, being typed in below:


@Summers Interesting solution. I don't know what FIDs are, or what disabling them would do, and a google search was not very enlightening. Could you elaborate?

New Contributor III

I'm also experiencing this problem and will be raising a support ticket with Apple Enterprise.
I'll post any useful info here. It's also worth noting the OnTap version in use (8.3p2 in our case) as fixes for Adobe saving issues were apparently applied with this version (even though we still have the kernel panics).

Also, we've found "resharing" NetApp volumes with Group Logic's Access Connect (Extreme-ZIP) to be unusably problematic (progressively slow experience for users and high CPU on the server). I'd be extremely interested to hear from anyone who is successfully using this method..

Basically, I'm struggling to find a way to use the NetApp with macs in a reliable, stable manner.

New Contributor II

@benshawuk Thanks for offering to follow up with more info. I haven't looked into it much since originally posting this.

I hadn't heard of Access Connect before. I'm going to bring it up to our server admin as a possible option, and see what he thinks about implementing it. Are you hearing of others having similar issues with it that you are?

New Contributor III

@ihalvorson It works great with locally attached server storage. However, the "resharing" functionality (required for serving NetApp shares over AFP) exhibits this severe performance problem, and I've yet to speak to anyone who has it working properly (without this problem).
It's fine under test conditions, but when lots of users are connected, it slowly grinds to a halt.
It's also very expensive (though to be fair, so is the NetApp, so perhaps it's all relative).

Unfortunately we've found that using SMB vs AFP with NetApp is simply swapping one set of problems for another. I've heard of people downgrading the version of SMB that the mac clients use (also with the nsmb.conf file) but even doing that comes with it's own set of issues.
Stuck between a rock and a hard place, it's all quite frustrating.

In other news I've tested the "file_ids_off=yes" workaround (as described in this thread), and it seems to improve things a little, though the problem still occurs (every 20 or so saves, rather than every 5).
Have your users got used to working locally or putting up with kernel panics?


Bump... still seeing these kernel panics on OS X v10.10.5, with Adobe CC 2014 Illustrator and Photoshop, and SMB shares.

Does anyone have a solution?! It's astounding that this hasn't been fixed in all this time.