2014-12-12 07:59 AM
we recently migrated Groups data from Novel to cDOT. Since that, clients (SMB2.1) experience problems accessing files that are shared by Excel to multiple users.
- Performance issues come along with that problem
When user accesses the shared Workbook, he get error "The document is locked for editing by another user"
Then hitting the unlock button takes couple minutes
after accepting couple error messages, saying that the file is blocked, file opens and eventually also with write access.
Of course, because the file is shared, other users have the file open in parallel, but MS Office should handle that, but
How to set the volume share in CDOT to allow that feature to use?
Currently these are the settings we use:
Share Properties: access-based-enumeration browsable changenotify Symlink Properties: enable File Mode Creation Mask: - Directory Mode Creation Mask: - Share Comment: - Share ACL: Everyone / Full Control File Attribute Cache Lifetime: - Volume Name: volume_1 Offline Files: manual Vscan File-Operations Profile: standard
2014-12-14 09:51 PM
I think your question relates more to how the CIFS protocol is implemented. I don't believe this is a NetApp specific configuration issue (oplocks should be enabled) but rather a CIFS protocol issue. Note that you would experience exactly the same issue if the excel spreadsheet was accessed by multiple network clients on CIFS shares hosted on a Windows Server. For more detail on oplocks see:
Opportunistic locks and the associated operations are a superset of the opportunistic lock portion of the Common Internet File System (CIFS) protocol, an Internet Draft. The CIFS protocol is an enhanced version of the Server Message Block (SMB) protocol. For more information, see Microsoft SMB Protocol and CIFS Protocol Overview. The CIFS Internet Draft explicitly identifies that a CIFS implementation may implement opportunistic locks by refusing to grant them.
IE...if a network client accesses a file using the CIFS protocol and that file is already locked, the lock must be released before the document can be modified.
See the "Considerations for shared workbooks" in the following Excel support blog:
NOTE: You can automate the process of having to manually unlock files to avoid administrative burden. Here are some examples i've posted:
2016-11-30 06:26 AM - edited 2016-11-30 06:28 AM
We have the same issue like described. It started the moment after we migrated our cifs environmnet from a 7mode controller to Clustered ONTAP. Besided the NetApp, the environment stayed te same, so definitely something changed on the NetApp side in the file handeling.
In the meantime on the NetApp side, I disabled oplocks and offline files on the share and I changed cifs version back from SMB3 -> SMB2 -> SMB1. No succes.
On the client side (Windows 7 with Excel 2010), we have the latest updates. I followed suggestion from https://blogs.technet.microsoft.com/the_microsoft_excel_support_team_blog/2012/05/14/the-definitive-locked-file-post-updated-772014/ and enabled EnableShareDenyNone & NoOpLock. Also on the client side we changed from SMB2 -> SMB1. All with no succes !
It may look like an Excel problem. I'm quite sure it is related to NetApp (migration). We are 100% sure that the cifs protocol has been rewritten in cDOT, since there is also incompatibility with mounting cifs to an AIX system now (that worked before, although unsupported). We also see slow delay an deleting on some system since migration, which are under control with changing oplocks/offline files settings. I think rewritting the protocol may have been an influence in the excel handeling. Finding the right parameter to change it back to normal behaviour is apparently hard to find. Suggestions anyone ?