SMB + Adobe = kernel panics

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.

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?

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

http://www.adobe.com/support/techdocs/332534.html

https://helpx.adobe.com/photoshop/kb/networks-removable-media-photoshop-cs5.html

@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.

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.

@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?

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.

@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?

@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.