We help IT Professionals succeed at work.

Unable to save Excel files to shared network drives

Medium Priority
Last Modified: 2010-04-21
OK, I got a tough one for you guys..  I have a couple users that are not able to save Excel files, and only Excel files, to any network shared drive, when they try, they get a set of errors that say Disk is full and Unable to save file.  Now, before you ask, no, there are no disk quotas, and yes, both their local PCs and the servers hard drive have plenty of free space (30-60gb on their PCs, 300+gb on the server).  They can save Excel files on their local PC, but not on any network shares, mapped or unmapped.  Ive installed the latest service packs and software updates for both Office and Windows XP, as well as on the Windows 2003 server. I also cleared their temp folders and emptied their recycle bins.  They have no problems saving Word files and they're able to copy files to network shares. They can delete files from the shares, can move them, and they can create new folders..  everything works except for saving Excel and it doesnt matter if its an existing file or a brand new file, they all return the same Disk is full Unable to save file errors.  I do know that this only happens from the desktop PCs, anyone that connects to the company's terminal server is able to save Excel files to the same locations without problem.

Anyone have any ideas?
Watch Question

http://support.microsoft.com/?id=296264 implement this.


Just out of curiosity, what happens if you save the file locally and use a copy operation to paste it into the target location? Do you get the same error? What file extension are you saving in? Does it differ if you save out the file as a CSV or XLT file?

Are you running any sort of endpoint client security product on the local machines?


Saving the file locally, then copying the file over manually works fine.  In fact, that's the work-around that I have them doing now.  I created a local folder that they're saving to, then executing a batch script to copy all of the files from that local folder to the server.

These are all .xls files.


Nikhil,  what are the reprecussions of disabling opportunistic locking?  I see that by default, this is enabled.
lemme find a document for the same... i dont think there are any extreme effects though.

How many users are affected? After re-reading your post, this question was raised in my mind.

Are the clients running a client-level AV product that is set to scan network shares also? It may be possible that the AV program is interfering with the Save operation from within Excel.

How long has this been an issue? Were they able to save before and now they cannot? What's changed in the environment?


There are about 6 desktop PCs that are affected.  They are all running McAfee Anti-Virus 8.0 set to scan only local drives.

This became an issue last week when we migrated all of our users to a new server with a larger capacity.  When we migrated the files, we copied, not moved, the files to the new server and recreated the network shares with the same user permissions that the old server had.  This is also the same server that is the company's terminal server.  When the affected users connect to the server through terminal services, they are able to open the Excel files and save them locally, but cannot save the Excel files through the network share.  There are no errors in the event viewer to coordinate with.  We tried copying one user's directory to another server in the domain, and the same problem occurs.

Also, I just found out that any time a user attempts to save an Excel file through the network share, the server will bluescreen within 5 minutes and restart.

Wow! That is interesting. Is the other server available? Are there any other servers available? If so, what happens when you save out of Excel to them? If the condition is the same, then you are looking at client issue. If they can save to the other server fine and not the new one, then you have a server issue to deal with and I would recommend a server-level debug on what is happening when you execute the save operation. You will need a suite of monitoring tools and you will need to pick up the network traffic to and from the server, the running processes and their dependencies, a file, disk, and registry monitoring tool and compile all the data to see what is happening. The BSOD and server crash is what concerns me most and may be indicative of a hardware issue, a NIC driver issue, or malware.

We need to isolate what is being sent to the server at the time of the save operation and if what the server sees is what the client sends. At the same time, we need to know what processes are running and which, if any, become active at the time of the save. We will also need to know at the same time what parts of the registry are being accessed or modified, what is happening on the hard drive and what files were being used at the time. It would also be helpful to capture the debug of the system crash and see what information is in there to help us troubleshoot the issue. I would further recommend a executable/port monitor to see if there any other executables running on the machine and if the approriate services are listening on the proper ports.

You are correct in the fact that this is a tough one.

Without having any further information and just following my gut, from what you have described and due to the very specific and limited nature of what is happening - coupled with the BSOD, my feeling is that you have some malware on the server that is causing this issue.


Only problem with that theory is the only program that is affected is Excel.  I can open/modify/save Word files all day long without incident, but Excel fails to save every time.  This is also not server dependent as I was able to duplicate the problem with another server, same files, same results.  I will be back in the office tomorrow to be able to bring the old server online and see if it's still able to save Excel files.
After rereading one of your posts I happened to notice one statement you made about the Terminal Services Clients when logged into the server via RDP and they run Excel (locally I would presume) and save locally that it is OK. However, you also mention that when these same clients try to save to a network share, the same problem exhibits. Did I read that correctly or are you saying that these same clients when they try outside of RDP they are still getting the error?

Just for curiosity purposes, have you taken a different machine, performed an OS and Office reload and then tried to save an Excel document to any network share?

Regarding my last post, I realize that the only affected program is Excel and if the server weren't crashing after they attempt, I would simply say that there is an error at the client level that will most likely only be solved by a slick and reload. Sometimes, the time spent troubleshooting exceeds the time spent simply reloading everything. I know it's using an elephant gun to go gnat hunting, but sometimes weird things happen. Even though you are running AV, that's not to say that somehow you still didn't pick up a worm, or rootkit or some other malware that is specific to Excel and is interrupting your communications and at the same time crashing your server. This theory is best isolated by using a client known to be "clean" because everything was reformatted and reloaded.


Here's the scenario:

Terminal server - Windows 2003 Server running Terminal Services
  - Has network share for data files
  - Allows network thin clients to connect to server

Desktop PC User - Windows XP Professional w/ SP2
  - Connects to network share on terminal server \\terminal\users, unable to save Excel files
  - Connects to terminal server via RDP, able to save Excel file to same folder, but through local drive instead of network share, D:\users

Both instances, it's the same folder, but in one scenario they're connecting by using the network share \\terminal\users,  the other through D:\users

Krais, have you come up with a resolution to this issue yet? I'm having the exact same problem on my network - with a much larger user base being affected.


It ended up being an issue with group policies that were in place with a previous terminal server.  I reset group policies to default using secedit and rebuilt the group policies that I had needed for Internet Explorer security and software installation rights.

I used the compatws.inf template for the terminal server, but obviously you wouldn't want to use that template on any domain controller in your organization.


Thanks guys for your help.  I've split the points according to time spent with the question.  Appreciate the attempts to help.

I have encountered the same problem recently.
Manage to solve the problem by set the speed of the port to AUTO at the switch end.