Can't Save or Re-Save to Server
Please note that this article has been updated several times and the complete history (including various workarounds to the problem) can be viewed by starting at the bottom and reading each successive section.
The Latest: December 2010
Word 2011 will not save to a server whose name is "files" or contains "files" as part of its name. Go figure...
There are other issues as well, and currently we have no idea what is causing them or how to fix them.
The Microsoft software engineering team has a Severity 1 incident open on this issue, so we can expect a speedy resolution.
There is also a general issue with Word 2011 being unable to save or open files that have special characters in the name or path.
Office 2008
There are issues getting anything to save to networks from Office 2008. The errors are variously reported as:
- Files are reported as "in use" when they're not
- Files will save once only, then return a "Disk is full" error on the second save
- The "new" file formats will not save but the old ones will (so you can save .doc but not .docx...)
The issue appears to be a Snow Leopard bug, and Apple is working on it.
Your first action must be to check with Apple Software Update that OS X is at the very latest update level. Updates are being released frequently, and if the problem system does not have the latest updates, then updates released by other companies may not be able to work.
The next step is to go to Help>Check for updates in Word and make sure Word has the latest updates. This is particularly important if you have re-installed: a re-install can take the software back to a state of "no updates applied" and rapidly make the problems a great deal worse!
In the meantime, user Chris Eads reports on http://www.macwindows.com [NOTE: outdated link removed by Lene Fredborg 30-Dec-2017] that he has found a fix. MacWindows is a great site to keep an eye on: useful stuff comes up there constantly! As always, "caveat emptor..."
Chris writes: "After spending a few days on this one, we figured it out.
The Problem:
We joined the 10 or so Macs in the company to our Active Directory domain and in the magic triangle configuration (Mac OS X 10.6.2 Server). When the Macs were independent of the domain, and the users were connecting to the shares using their domain credentials, everything worked fine. When the Macs got hooked in via the directory plugin, users could create a file in Illustrator (for example), and save it once. You could not, however, save it a second time (sometimes third). Illustrator gave a "file is locked ID = -54" error of sorts.
Solution:
In a long session of trial and error, I tried saving to the administrative C$ share on my Windows 7 desktop, which was owned by "NT SERVICE\TrustedInstaller". Creating a share on Win 7 had the same error behavior as before, when the shared folders owner was changed to TrustedInstaller, it worked fine. The following challenge was to port that solution to a XP/2003 environment, which doesn't have that account. My boss, out of a leap of logic, tried the "NETWORK SERVICE" domain account as the owner of the folder on 2003, and everything works. Obviously the sharing/NTFS permissions have to be set properly on top of that.
Chris discovered the procedure also works to fix the Snow Leopard problem of saving Offices files to SMB servers on Active Directory networks.
He writes: "I've verified the Office saving issue is resolved with the fix.
I tried saving files out of Office 2008 to a non-Mac-friendly share, and then on of the ones where we've changed the NTFS owner to NETWORK SERVICE, and doc, docx, xls, xlsx files save fine. Tested on both 12.1.0 and 12.2.3."
|
Another contributor expanded the advice a little. He writes: I initially tried giving NETWORK SERVICE ownership, but it didn't work. I figured out an extra piece. The NETWORK SERVICE account needs to have ownership of the root of the share. Here's the scenario: On the server (member of 2k3 domain), a folder called "Level 1" has a bunch of files and a folder called "Level 2" inside it. The "Level 1" folder is shared as a share called Level 1 and the "Level 2" folder is also shared, as a share called Level 2. NETWORK SERVICE is given ownership of the Level 2 folder. A Word .docx file is in the Level 2 folder. Connect to the Level 1 share and navigate to the Level 2 folder. Also: connect to the Level 2 share directly. You are now looking at the same file, but connected to it in two ways. Opening the file from the Level 1 share will allow you to save once, turning it into a read-only file. Opening it from the Level 2 share instead allows you to save as much as you want. If you give NETWORK SERVICE ownership of the Level 1 folder, then the problem is gone. You can save as much as you want, whether you connect to Level 1 and navigate to the file, or connect to Level 2 directly. There is a warning here: If you have a folder within these shares where you have removed permissions for most accounts, including administrators, you can blow away the permissions by taking ownership. If the server does not have permissions to the folder (if the managers have permissions but systems administrators do not for confidentiality reasons)the server can still take ownership. If you do take ownership, it will remove the access that was set up prior to taking ownership. That can be a problem if you have customized permissions in that way. We have a few folders here and there that are protected in such ways. |
Pre-Snow Leopard
From Dave Provine: Many people, but not all, have run into the Save to Server bug with OS 10.4.x and servers. The solution has been identified and is somewhat easily implemented. The problem is explained here: http://docs.info.apple.com/article.html?artnum=302979 [NOTE: outdated link removed by Lene Fredborg 19-Feb-2017] The local UID on the user's computer needs to be changed away from the default 501 or 502. (See "Note" below for more on this default.) If you open Terminal on their computer while they're logged in, and type "id" without quotes, it should return something like this: uid=1025(provine) gid=(staff) groups=(staff) If the uid is 501 or 502, that's bad. Change it to something much higher like 5263214. It can be a large number. It just has to be Globally Unique. This tip from http://forums.macosxhints.com/archive/index.php/t-12077.html will help you change the UID: Changing UIDs in the terminal is a simple NetInfo property overwrite: sudo niutil -createprop . /users/userName uid XXX (Replace userName as appropriate and XXX with the new UID number.) Finding and changing UIDs across the filesystem is a one-liner command: sudo find / -user UID -exec chown userName {} \;
(Replace UID with the old UID number and userName with the new user name to associate file ownership. Do not type a space between the brackets.) Note: Again, it's the LOCAL UID on the user's computer that is the problem. That's why it's somewhat random as to who gets stricken by it, and why users with Network Home Directories never have the problem. By default, they will always have different UIDs. The first local user on every OS X machine is UID 501. So unless everyone is using network logins, which is quite uncommon in smaller places, the problem comes up. It never, ever happens where OS X Server network logins are used or where everyone auths against Active Directory, since their UID is based on the server, and therefore must be unique. Regardless of what UID the user mounts the server volume with, people with the Save problem have logged into their personal Mac with a local account. At that point, their UID as far as Word understands is 501, and that's the UID it uses to name the temp files directory. |
February 2006
Rob Daly of MSFT (see next section) has just posted the following new information about this issue. Please read it carefully!
This post covers the scenario where Word cannot save to a remote home folder from a Tiger client through both SMB and AFP. Apple has diagnosed the problem to a bug (or implementation issue) with bit range-locking. The ETA for a fix is unknown at present (I will post here again when I have any public information). However, a workaround has been provided for the AFPonly side of the issue. GARGANTUAN CAVEAT:Employing this workaround may cause file corruption when the server is set up for file sharing over both AFP and SMB (in fact just more than one protocol). Bit locking is used to *prevent* this file corruption, so it is ill-advised to try this workaround if this is your setup. If you do not use multi-protocol file sharing, then this workaround should fix the problem until Apple can release a more complete fix: 1. Launch Terminal (Applications/Utilities/Terminal) 2. Run this command: sudo defaults write /Library/Preferences/com.apple.AppleFileServer lock_manager -bool NO Enter password when prompted. 3. You now need to restart the AFP service on the server. Do this when you have very little server traffic as it will boot everybody connected off. Rob Daly -- |
November 2005
The following analysis of this stubborn bug was written by Rob Daly of Microsoft and published to the microsoft.public.mac.office.word newsgroup in November 2005. Below the analysis is the history of this bug as written by John McGhie and documented on this website. Note that earlier "fixes" may still be of use and should be considered, especially in the case of Novell Netware users (see below the box).
"Can't Save To Server" Bug
|
History:
This issue, which has been attributed to a problem in the Apple OS, appears to have been resolved with Apple’s OS X 10.3.3 update. Your best bet, therefore, is to update as soon as possible.
Novell Netware users click here...
The original text of this article was:
The OS X 10.2.4 update was supposed to resolve issues between OS X clients saving Word documents on Windows SFM fileservers as well as AppleshareIP fileservers and MacOS X fileservers. Patch level OS 10.2.6 offered further improvements to some networking components.
Those who have Mac OS X Servers running 10.2.3 should upgrade to 10.2.4 or above.
Unfortunately, these patches didn't fix the issue. The patches are well worth having: issues with other software are resolved. However, Microsoft Word uses a very complex conversation with its server, to enable all sorts of things that other applications simply can't do with their files (for example, ensuring that nobody can change a document while you are reading it, or telling you "who" has the document open if you can't edit it). The more complex parts of the file exchange protocol between the server and the workstation have not yet been fixed. There is a work-around below.
Cause
The error message you see "Unable to Save: Disk Full or Too Many Files Are Open" is a generic "Sorry I am unable to save" message, and it can be caused by anything that prevents Word from obtaining an acknowledgement of completing its write to disk, including userID permissioning errors, failed network connections, more than about 9 documents open at once, inability to store or release its lock file on the server, or even the reason stated!
However, the cause we are most familiar with on the Mac is due to bugs in the transport between OS X and the file server. Apple and Microsoft introduced changes to overcome a security hole a few months ago, which caused the data stream between the client and server to be authenticated more strictly, and this has exposed errors which have been there forever.
For an OS X server, these were supposed to be resolved if the server patch level was at or above OS 10.2.4. For Windows Servers, the errors are not exposed unless the Windows Server is at or above SP 3. For Novell servers, we have no idea and are desperately seeking...
The issue is with the way Word "streams" a file to or from storage. The problems are not exposed in other applications, because they do not attempt to open multiple connections with the file server.
Work-Around
One work-around that is partially successful is to set the Word>Preferences>Save to ensure that Fast Saves is OFF and Always Make Backup is ON. This doesn't cure the problem, but on some kinds of servers, it raises the number of saves you get before you see the problem to around 60 saves, which is more than most users do on a single document.
When a user gets this error, they will find that if they attempt to save the document in RTF format to their local disk, they will usually succeed, thus preserving their work.
Until this bug is finally fixed, users can use Finder to copy their document from the server to their local disk, work on it there, then use Finder to copy it back again. Word must be quit, not just minimized, when you copy the document back to the server. The bug won't strike if both the file and its attached template are on a local drive.
Other than that, all you can do is keep your server and client patches up to the latest released levels and keep hoping: just like the rest of us.
To obtain OS X system patches, run Software Update, or download them from the Apple site [Lene Fredborg, 14-Jan-2020: Removed outdated link to http://www.apple.com/support/downloads/].