Network and Storage Protocols

CIFS Issues with Microsoft Excel 2010 after migration to cDOT 8.3.1


Hi All,


After a recent migration of CIFS files shares from 7-mode 7.3.3 to cDOT 8.3.1 users are experiencing issues with saving Excel 2010 documents on file shares when using Windows 7 Enterprise.

They receive the error "Document not saved" when attempting to save changes to a migrated workbook file thats exists on the new cDOT file share.

The only way to save to the network share is by saving the document to the C: drive, quitting Excel, and then manually overwriting the file back to the fileshare which works without issue.


Like all 'interesting' issues to track down, its not all users or shares that appear affected post-migration. A review of before and after 'share' and 'NTFS file rights' don't show any irregularities.

ABE wasn't enabled beforehand, and isn't enabled now. I guess the biggest change is that there is no longer SMB1 (just 2 and 3)?

By disconecting and reconnecting the network share that the user is trying to save to seems to allow normal operation however the issue returns after a reboot making me think its more of a machine/user profile/connection caching issue than a NetApp configuration one.


The new CIFS SVM on cDOT has a machine name of "NACIFS1" - it exists in DNS with its correct name as well as a CNAME of "FS1" and NETBIOS aliases of "FS1" and another legacy fileserver "FS2"

The old 7-mode system also used a different name from the CIFS instance machine name, with CNAME alias and NETBIOS entries so once again this is the same configuration as the original.


Are then any suggestions on how best to proceed to investigate further? or if you have seen something similar before?








Excel has a strange way of saving files.  It saves your work to a temp file, then deletes the original and renames the temp file.  If something goes wrong along the way you get that error.  There are hotfixes, office patches, registry tweaks, etc that may or may not resolve it in your particular case.  It could also be AV related on the client side.  Its probably worth opening a case on just in case its an obscure problem in the svm config.


If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.


Did you find a solution for this issue. We have the same after migration from 7mode to cDOT.