View Full Version : Mountain Lion Server causing Adobe Acrobat and Reader to crash on viewed PDFs
Jan 9, 2013, 06:36 PM
Last weekend I did a clean install of 10.8 with Server on my office's Mini Server, replacing 10.6 Server. The Mac clients have been fine, but I also have a couple of Windows 7 users, one of whom has been having serious issues.
The one that has me really baffled is with viewing large PDFs directly off the server.
If you open a large PDF with Acrobat Pro X or Adobe Reader XI and spend a while scrolling around it, the document will eventually either start showing blank white pages, Acrobat will give a generic "an I/O error occurred" message, the program will crash outright, or some combination of the three. How long and how much scrolling it takes can vary from a few seconds to a few minutes.
It happens with any large document (possibly small ones, too, but they aren't open long enough to show it), the same documents work just fine when viewed directly off the local hard drive, and this problem was NOT happening with a 10.6 server, so it has something to do with Apple's new in-house SMB implementation. (And I'd rather not install Samba if I can help it.)
What the heck is going on here?
Can somebody else running a Mountain Lion Server with a Windows 7 client try this? (Open a long PDF and scrub up and down for a minute or two.)
Jan 23, 2013, 12:24 PM
I am seeing the EXACT same phenomenon on our freshly installed Mountain Lion server.. also we are noticing that AutoCAD is crashing more often with large files, so this appears to be related to large files, not necessarily PDFs, though the PDF issue is exactly as you describe on our network as well...
Jan 23, 2013, 12:30 PM
How much swap space do you have allocated?
Jan 23, 2013, 07:13 PM
Well, I'm glad to know that I'm not the only one seeing this.
After a considerable amount of further experimentation, I have a couple of even stranger things to add.
For one, of the five Windows 7 boxes on the network, it turns out that three of them work normally, while two are experiencing this same behavior. Even stranger, while the two that aren't working are nearly identical in terms of hardware and software, and the two that seem to work are on Win7 32-bit, the third one that does work is functionally identical--hardware and software--to the two that don't.
The other is that I may be seeing some behavior similar to you, signalflow; at least once I got an odd error when trying to copy a large (~500MB) software installer over the network, but on a retry it worked. Also, the user of one of the problem machines has reported some random permission errors when attempting to copy files using Windows Explorer that seem to come and go, although I haven't been able to replicate those.
How much swap space do you have allocated?On which system? I've generally left everything at factory default values, and wasn't even aware of an available swap space parameter in any of the above.
May 8, 2013, 10:15 PM
We appear to be suffering from exactly the same symptoms on a clean OSX 10.8 Server. All file shares are behaving normally under the Mac client environment (AFP and SMB), but all our Windows clients (Windows XP and Window 7-64bit) are suffering from blank pdf pages after a certain timeout.
Basically we have the following scenarios:
1. Under XP clients; viewing these files is fine if you look at it straight away. After a timeout of less than a minute in some cases, the pdfs exhibit blank pages.
2. Under Windows 7 (64Bit); viewing these files is fine if you look at them within about 5 minutes. Somewhere between 5 minutes and 10 minutes, the pdfs again show blank pages and the program (Adobe Reader XI or FoxitReader) has file I/O errors.
Both the server and the client machines are pretty much clean installs (no customisations). All OS updates have been run.
The only exception is that we have had to do a registry hack (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters - OplocksDisabled REG_DWORD 0(default) or 1. Set to 1 to disable.) This hack has fixed another annoying bug we have been facing which was that people on windows machines could open files that were already open on other windows machines and take over their read/write permissions (eg. original first person to open file would soon be told by the respective apps that the file is now read only (upon trying to save their work), while the second person to open the same file was given read/write permissions).
The above PDF viewing bug appears either with or without oplocks set.
We have also tested to see whether disabling PDF protected mode (in Acrobat) would fix this problem of blank pages but it did not. Somewhere in the mac server's SMB configuration there must be a setting that is not quite right.
Has anyone managed to fix this issue? We do not want to go down the path of installing SAMBA or a Windows Server unless absolutely necessary. SAMBA apparently has other issues with ACLs (or so I'm told).
May 9, 2013, 12:35 AM
Just a follow-up. I believe, after extensive testing and much hair-loss, this issue has been resolved by doing the following (works for both XP and Windows7, not sure about other flavours of M$ products):
Regedit (run as Administrator):
The timer to set is:
Value type: Dword
Value name: SessTimeout
This is in seconds. I basically did a test of 3000 (decimal value), and the PDFs worked for 50 minutes. I am now doing a test at 10,000, and its still going strong.
I don't know of a more elegant solution, but this is going to be our "Fix" for the time being.
I hope it also works for you guys!! Good Luck!
May 9, 2013, 01:07 AM
Well that's very interesting. I'm going to compare the registry on the systems that were and weren't functioning on my network and see if that parameter is different.
My eventual solution was basically the nuclear option; I used SMBUp (http://eduo.info/smbup/) (free) to disable the new SMBX and replace it with Samba, at least for the time being. It's a bit crude in that it doesn't use the built in directory services--you need to manually select users to add and re-enter their passwords--so it wouldn't work well for a large system, but for my relatively small network it gets the job done.
I'll try switching back to the built-in solution eventually and see if they've worked out the kinks, and I'll be sure to give that timeout parameter a try if they haven't, but getting things working was a priority and I had run out of time to spend on it.
Aug 20, 2013, 09:28 AM
I want to thank OT-Mac for his fix. I've been tearing out my non-existent hair trying to resolve the disappearing pdf issue with absolutely no result. I'd actually reached the point where I was about to put in a business case to change over to a Windows server, because of the incessant, if justified, whining from our client services team, who work on a mix of laptops and desktops running either Windows XP or 7. Having applied the fix using the 10,000 value to all our Windows machines, they are now happily viewing pdfs, flash video etc over the network. This would also appear to fix any I/O errors that occur in other applications.
Once again, thank you and I hope everyone who has this problem arrives at this page - it took me long enough.
Aug 21, 2013, 01:11 AM
Mountain lions SMB server doesn't know how to handle timeouts, you are much better switching to NFS or Samba for this purpose. Normal SMB protocol will listen for a status message and refresh the connection before the client has reached the timeout period. Apples new SMB implementation doesn't handle this correctly and just allows the client to timeout, which in your case closes the connection while viewing a PDF document causing adobe reader to crash.
I reported this as a bug a while back, you guys should do the same so it can get eventually fixed. I am uncertain what apple's new SMB implementation (Old AppleShare IP software from OS 9?) came from, but it's by far not up to par with Samba.
Sep 11, 2013, 03:14 PM
...but on Windows XP for some reason it hammered my networking such that I had to do a System Restore to get it working again.
Most networking related services wouldn't start. Link Pipe was invalid, was the error for many of the services in the event log.
Services affected were DCOM, Computer Browser, Workstation and Cryptographic Services. There were a few more.
This is despite removing the hack. I had the same result on several XP boxes. I used a large value in the Sesstimeout field (8 hours) and perhaps thats why it didn't work, but I don't know why the problem persisted after removing the hack.
Windows 7 computers seem to be okay.