Excel and El Capitan Server: Cannot reopen the saved document due to low memory

Question

Level 1

0 points

Excel and El Capitan Server: Cannot reopen the saved document due to low memory

Hi Everyone,

We have a server that was just recently upgraded to El Capitan with the newest version of the Server app installed. We have FileSharing enabled with Open Directory for all network users. Network users logging in keep getting this error message when they save excel files on the server:

When that file is then re-opened, there is an error saying that the file is corrupt and would you like to try to repair. The repair never works.

This is happening 9/10 times for only Excel files on our Mac server across different computers and users. Open directory was re-built and users re-added but we have the same issue. All users (about 8) are using Macs with Yosemite and El Capitan. All users are using Office for Mac 2011. Server was running OS X Mountain Lion with server prior to this, so we went through an Erase and Install to make sure we started with fresh settings. All data is stored on a separate internal hard drive "Data HD" and is separate from the Server HD where the OS is installed. Permissions for Data HD and all shared folders within were re-propogated so we're 100% sure they're accurate throughout. Server has 16GB of memory, so I highly doubt it's actually a memory issue. Users are able to save Excel files to their desktop from the server fine, so it's definitely Server-related.

All was working fine with the previous OS. Any suggestions would be super helpful. I'm pretty Apple tech-savvy, but this one has me stumped.

Thank you.

Tim

Mac mini, OS X El Capitan (10.11.3)

Posted on Feb 7, 2016 4:37 PM

Reply

Answer 1

UptimeJeff

Level 4

3,479 points

Feb 7, 2016 4:46 PM in response to THDTim

Did you test AFP vs SMB ?

Default is SMB.

Try forcing AFP by using: afp://<server-IP>

If the issue effects SMB only, then either turn SMB off (my preferred solution when there are no windows users) or enable ACLs for SMB.

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server lock -bool YES

You didn't say exactly what permissions were propogated and whether they were ACL or POSIX.

This article might help also.

Can't save to an OS X Server share point that allows write access - Apple Support

Jeff

Reply

Answer 2

THDTim Author

Level 1

0 points

Feb 7, 2016 5:02 PM in response to UptimeJeff

Hi Jeff,

Thank you so much for your reply. We have had issues with SMB in the past where even one folder thats got SMB turned on throws everything off, and we made sure that the iOS and SMB sharing options when setting up the file share were deselected; so all fileshares are confirmed AFP-enabled only.

After file shares were setup, we propagated permissions in Server > Storage > Action Button > Propagate Permissions. It's just ACL that we propagate typically.

That article that you linked was an interesting read, but could you clarify if there's something special I need to do to "Use Server app or Server Admin to allow delete access on the share point". All users have Read and Write access to the appropriate file shares.

Thank you again for your help!

Tim

Reply

Answer 3

UptimeJeff

Level 4

3,479 points

Feb 7, 2016 5:05 PM in response to THDTim

Propogating an ACL does nothing if you didn't actually setup an ACL for the directory.

Send results of:

ls -aled /Volumes/Data HD/path-to-shareoint

Reply

Answer 4

THDTim Author

Level 1

0 points

Feb 7, 2016 5:18 PM in response to UptimeJeff

Thanks Jeff,

Here are the results of Is -aled for the fileshare "Clients". "ladmin" is the machine's local admin and "staff" is the group on the server that includes all users within the company.

Server:~ ladmin$ ls -aled /Volumes/Data\ HD/Clients

drwxrwx---@ 59 ladmin staff 2006 5 Feb 19:40 /Volumes/Data HD/Clients

0: user:_spotlight inherited allow list,search,file_inherit,directory_inherit

1: group:staff allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextat tr,writeextattr,readsecurity,file_inherit,directory_inherit

Thank You.

Tim

Reply

Answer 5

UptimeJeff

Level 4

3,479 points

Feb 7, 2016 6:35 PM in response to THDTim

Your ACE is missing 'delete'

# Yours

list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextatt r,writeextattr,readsecurity,file_inherit,directory_inherit

# Should be

list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,reads ecurity,file_inherit,directory_inherit

The apple article above describes exactly this issue. Safe Save apps require the delete priv.

Jeff

Reply

Answer 6

THDTim Author

Level 1

0 points

Feb 7, 2016 7:21 PM in response to UptimeJeff

HI Jeff.

THank you so much-! This makes sense. The article doesn't quite explain the steps to go about getting this done. Can you tell me or get me in touch with a resource that can show me how to adjust this permission?

THe the article only says:

Use Server app or Server Admin to allow delete access on the share point.

Thank you.

Reply

Answer 7

UptimeJeff

Level 4

3,479 points

Feb 8, 2016 7:05 AM in response to THDTim

In the Server app, there are two ways you can set permissions.

File Sharing

Convenient, but it only provides 3 options

Storage

Find it here:

Navigate to your sharepoint and you'll find more granular control over permissions.

Above are the permissions assigned when you set 'Read & Write' from the File Sharing section.

You can see 'Delete' isn't enabled but 'Delete Sufolders and Files' is enabled.

Apple's article isn't clear and I'm not positive this will be a solution, but definitely worth trying.

Tick the delete box, then use the gear to propogate permissions (ACL)

Hopefully that solves it.

Reply

Answer 8

THDTim Author

Level 1

0 points

Feb 15, 2016 2:50 PM in response to UptimeJeff

Hi Jeff,

Thank you for all of your help. Unfortunately this didn't resolve the issue. We have set all share point permissions to include Delete, and yet the same issue with Excel files is present.

We have updated client machines to El Capitan as well to see if this fixes the issue to no avail. It's on El Capitan, Yosemite and Mavericks machines (all that we have tested).

Any other ideas?

We're going to turn on SMB for all file shares tonight and see what kind of result we will get, just to try something.

Thanks.

Reply

Answer 9

THDTim Author

Level 1

0 points

Feb 21, 2016 7:34 PM in response to THDTim

This is very strange to me. After adding SMB to all of the file shares, and telling users to manually reconnect to the server in Finder (so that it will default to an SMB connection) the issue has disappeared. So it looks like enabling SMB allows Excel to not have this issue.

Apparently there's still an ongoing issue for users where Microsoft Word is also crashing. Though that is an issue for another thread. Thanks for all your help with isolating this issue, Jeff. Much appreciated.

Tim

Reply

Answer 10

Feb 29, 2016 6:40 AM in response to UptimeJeff

OMG! Just discovered this thread while searching for a solution to the same problem.

I'm not that tech savvy, certainly not a coder, and I don't understand what all the SMB talk is about, I'm just a normal user of Word and Excel on my Mac.

Since upgrading to El Capitan I can no longer save my spreadsheets to my desktop, the only option that is available to me is to save to Office 2011 Autosave Folder. When I look for the file on my system I can't find it but when I click on Excel to open a new spreadsheet it opens the last one saved to Autosave Folder. any new worksheets I make have the same problem .... unable to save to desktop.

Is there anyone out there who can describe what I should be doing to rectify this .... but in easy to understand steps, that a basic user can understand?

I would be very grateful for some help with this nuisance issue .... did ever arise with the other OS before updating to El Capitan. Arrrrgh!

Reply

Answer 11

Backspin

Level 1

19 points

Apr 5, 2016 5:41 AM in response to THDTim

I had the same problem, and it appears to be a bug in Quicklook in El Capitan, at least up to 10.11.4.

When you open a Finder window in Icon or Column view (the latter with the problem file selected), and you have Icon Preview enabled (which is default), then Quicklook wil generate a preview icon for this file.

However, when the excel file contains a formula (any formula, even 1+1) then Quicklookd will never let go of the file and keep it open. You can verify this in the terminal with 'lsof', or with Activity viewer when you inspect the open files of the 'QuickLookSatellite' process (there can be multiple QuickLookSatellite processes).

Now, when Excel tries to save a file, it creates a temporary file, saves to contents to this file, and then tries to replace the original file with this temporary file. On network shares, this fails because the file is still open by Quicklook. This will cause the (misleading) low memory error in Excel.

In my tests, this was the case with both AFP and SMB shares. It could be that you didn't experience this bug with SMB because you didn't have the Finder in Icon view.

On local filesystems, it's a bit weird. Quicklook seems to keep the excel files open, but you are able to save them. However, when you try to delete such a file, Finder will give an error that the Trash can't be emptied because the file is still open.

This bug is with El Capitan and /System/Library/Quicklook/Office.qlgenerator version 5.0. Yosemite with Office.qlgenerator version 4.0 doesn't display this behaviour.

I filed a bug report, but if you have this problem as well: please file a bug report.

Workaround: disable Icon preview in all Finder view modes. Workaround when experiencing this bug when saving a file: save the file with a different name, or (with Activitiy monitor) force kill all QuickLookSatellite processes, and then save the file.

Reply

Answer 12

THDTim Author

Level 1

0 points

Apr 5, 2016 5:46 AM in response to THDTim

Thanks Everyone for all your comments!

Just a followup to let you all know what's happening. So I mentioned in what I tagged as the "solution" that now Word doesn't work for users. It looks like the SMB thing wasn't related at all and needed to be reverted. Instead, Office had to be upgraded to the very latest Office 2016 edition for Mac. There appeared to be just ongoing sporadic compatibility issues that we were finally and comprehensively able to resolve after doing this.

So in summary this is everything that fixed it:

- Upgraded server to El Capitan

- Upgrade all client machines (all mac) to 10.10 or 10.11

- Upgrade all client machines to Office 2016

No more tears!!

Although it really ***** that this turned into rolling updates and upgrades across everything, at least we know we won't have to deal with this again for a while.

Thanks again!

Reply