Start a Conversation




5 Posts


June 21st, 2023 08:00

Troubleshooting Misattributed Excel File Locks over Network Shares.

Our team has been grappling with an intriguing issue pertaining to Excel file access over our network share. We have a subset of users who frequently engage with a specific shared Excel file. Normally, in the event of a 'file is locked by' message, the identified user would simply close the file, enabling others to proceed with their edits.


Recently, however, there's been a perplexing anomaly: the 'file locked by' message incorrectly identifies the user who has the file open. Upon inspecting hidden system files, we notice the temporary '~$' file, which indicates that the file is in use. Curiously, the security tab lists the misattributed user as having the file locked - a claim we know to be inaccurate.


We have deduced that the persistence of the '$' file is likely due to instances where the user in question has lost their VPN connection while the file was open, typically because of an internet outage or a dropped mobile hotspot (MiFi) connection. This scenario appears to result in the '$' file remaining, falsely signaling that the file is still in use by the disconnected user.


To provide a brief overview of our setup: we operate from a Client -> VPN -> DFS Namespace -> SMB share on a Dell Isilon. When trying to identify the actual user with the file open, we refer to the backend of the Dell Isilon, where we run commands to locate the open file and fetch the user's session data.


Our team transitioned to the Isilon a few months ago, prior to which we used an SMB share from a Windows server. Encountering the 'file locked by' message is a routine part of our operations, but the issue lies in the incorrect user attribution. Furthermore, we've observed that even if the user reopens, saves, and closes the file, the '~$' file stubbornly persists.


It's also worth noting that in the absence of the file being open by any user, normal file editing operations proceed smoothly with no error messages.


Our current workaround involves identifying the true user with the open file, instructing them to close it, and manually deleting the residual '~$' file.


Does anyone have any insights or alternative solutions to this perplexing issue? Any thoughts or suggestions are most appreciated! we are curious if this is an issue with SMB share on the Isilon or a weird issue with excel...


Best regards...



6.8K Posts

June 22nd, 2023 04:00

Hello AlteredAdmin,

Here are few links that maybe of assistance.

June 22nd, 2023 05:00

Thank you for your response. I understand the provided KBs focus on directory permissions, however, our permissions appear to be correctly configured. The issue we're facing concerns the temporary files that Excel generates (those with a ~$ prefix) when a document is open and the user experiences an internet, VPN, or power disruption.

The only significant backend change we've recently made is a transition to Isilon. We understand that Excel inherently creates and subsequently removes these temporary files. However, when our system was operating on a Windows server for SMB, we did not encounter this issue, even during the extensive remote working periods necessitated by the COVID-19 pandemic. It seems that this problem has only arisen following our move to Isilon.



6.8K Posts

June 22nd, 2023 17:00

Hello AlteredAdmin,

For this issue it is best to open a support case as there are a few things that will need to be looked at to see what is going on.

60 Posts

June 22nd, 2023 21:00

if you still have access to the old fileserver you might try to compare smb settings like oplock etc. just a wild guess...

No Events found!