This is an automated archive made by the Lemmit Bot.

The original was posted on /r/storage by /u/AlteredAdmin on 2023-06-21 15:42:44+00:00.

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 using the Isilon commands, 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.