How can we help you today?
File Locking Details
File Locking Operation
MyWorkDrive is developed to interact with Windows SMB file sharing to place and read locks on Microsoft Office files when opened for editing.
When Microsoft Office files are opened using the MyWorkDrive Web Client, Mapped Drive Client, Mobile Client or Office 365, locks are set and checked to ensure consistent interaction with SMB sharing. Files opened by MyWorkDrive users will show as locked to SMB users. Files open by SMB users will show as locked to MyWorkDrive users. Users will receive the same message in Microsoft Office that the file is in use will be prompted to open the file in read only mode, open a copy or wait for it to become available.
A special note about co-editing with Office 365. MyWorkDrive supports co-editing in Office 365 through the Web Client. If office documents are opened in Office 365 Online using our Office Online feature, they may be opened simultaneously by multiple users allowing documents to be co-edited online.
If an office document is already open in another client and a user opens it in Office 365, the user in Office 365 will receive the standard warning that the office document is locked for editing. Mixed mode is not supported. All editors of the document must be editing via Office 365.
Likewise, if a user attempts to open a document in local office which another user has open in Office 365, they will not be able to co-edit with them, they will receive the warning that the file is already in use.
Contents
Locking Technique
When a user requests to open a file via MyWorkDrive, MyWorkDrive conducts three seperate checks to see if a user should be able to open a file for editing.
First, MyWorkDrive checks to see if another MyWorkDrive user has a lock on the file. If they do, the file is treated as locked if the existing and requesting user are not both using Office 365 (see note above about co-editing).
Second, MyWorkDrive will check via SMB if a lock exists in the form of an owner or lock file on the file system. If it does, MyWorkDrive will treat the file as locked. This ensures the file is not open by a local user outside of MyWorkDrive.
Finally, MyWorkDrive will check to see if it can obtain a write lock on the file. If it cannot, the file will be treated as read only. This is to ensure the user has write access to the directory and will be able to save their changes.
Timeouts
MyWorkDrive uses a “timeout” system to ensure that file locks are not set permanently.
MyWorkDrive will automatically set a timeout of 15 minutes on any document opened in Local Office, and 20 minutes for any document opened in Office 365. These timeouts will be extended as long as the document is open for editing and the MyWorkDrive client where the file is open is still connected to the MyWorkDrive server. A user can open and work in a document for an indefinite period of time as long as they remain connected to MyWorkDrive (until they reach the allowed client session timeout as set by the administrator – at which point their client will be logged out).
Should the MyWorkDrive client become disconnected from the MyWorkDrive server, the lock will not be renewed and the MyWorkDrive server will automatically clear the lock at the expiration time.
This prevents a situation where a user who is no longer connected holds a perpetual lock on the file. Examples of this might be… a user steps away from their computer for lunch with a file open and the client computer goes to sleep. Or a user leaves work for the day with a file open and their laptop is asleep in their shoulder bag. Or a traveling user goes out of internet connection range with a file open.
If the user who has the lock re-connects to the MyWorkDrive server with the file still open before their lock expires, the lock will be extended – The traveling user regains internet connectivity, or someone who closed their laptop to walk down the hall from a conference room sits down at their desk and opens their laptop back up.
The timeout system serves the needs of temporary internet disconnections and permits the resumption of work without permanently locking other users out of a file.
Troubleshooting
Users may occasionally report that when they attempt to open a file to edit that it is “in user by another user” and they are presented the standard office options of open read only, open a copy, or receive a notification when the file is available.
Usually this is a valid warning – which they would receive whether they opened the file via SMB, VPN or MyWorkDrive – and indicates someone else is working on the file.
If the user is certain the file is not in use, or has a recurring pattern of unexpected file locks, a series of checks should be completed to review the complaint.
Before spending significant time tracking down transient file lock issues, its important to be sure that the environment is healthy and not causing / contributing to the issue.
The first thing you should do is verify that your file shares are setup by best practices to avoid users taking ownership of files and locking files as read only to other users. Please review our guide on file sharing.
Incorrectly setup file shares where users can take ownership of files or a mixed combination of conflicting share and NTFS permissions will result in users who cannot write the file and/or users unexpectedly taking ownership of files and leaving owner/lock files on the file system.
MyWorkDrive Locks Page
As of version 5.4.3, a list page of locks is available from the Shares tab in MyWorkDrive Administration, which shows you what files are open and locked by MyWorkDrive clients. This will show you details about who has the file open, from where, and the timing of the lock creating/expiration. Keep in mind if the user is actively editing the file, the lock will continue to renew and extend.
If the lock is manually released and the user still has the file open, the user may over-write changes of other users or be unable to save their own changes and lose them. It is not advisable to release a lock without first speaking to the user who has the lock and verifying that the file is, indeed, no longer needed. When speaking to the user, you should ask them to close the file in lieu of force releasing it.
You may also instruct the requesting user to wait until the lock period expires to proceed with their file edits, to permit the MyWorkDrive server to cleanly remove the lock and associated temp files.
The MyWorkDrive locks page will not show you locks open via SMB connections or other applications like antivirus or backup software. For that you should use Open Files on the File Server.
File Server Open Files
In computer management on the file server (not the MyWorkDrive server), you can see what files are open by users including MyWorkDrive.
https://activedirectorypro.com/view-open-files-windows-server/
This is a good way to note that files may be open locally by users via SMB or a VPN. The MyWorkDrive beta locks page mentioned earlier would not show any activity outside of MyWorkDrive, as you would see with this procedure.
If you are not using a Windows File Share, your SAN/NAS Solution may contain a method for you to review that information. Some examples
NetApp
https://library.netapp.com/ecmdocs/ECMP1196891/html/GUID-D2865527-345D-405A-91EA-70D2F97063BC.html
Dell EMC
https://blog.stealthbits.com/emc-file-activity-monitoring/
Morro Data
https://support.morrodata.com/support/solutions/articles/14000036232-files
Note: Locks from MyWorkDrive will show up as Read locks, which work fine with Office applications via SMB. If you require read-write locks to support 3rd party lock replication tools or replication file systems, contact MyWorkDrive Support.
Owner File
As of MyWorkDrive server version 6.2.1.7, MyWorkDrive proactively monitors for and removes orphan owner/lock temporary files, eliminating the “hidden owner lock file problem”.
It is no longer necessary to manually remove these files when using server version 6.2.1.7 or later.
When the software detects that Office hasn’t correctly removed an old temporary lock file, it proactively removes it. This prevents temporarly lock files from being orphaned and eliminates the erronous report of the file being locked when it shouldn’t have.
Of course, if the owner file is valid/active (ie, an indication of an active edit on a file), then no action is taken and the file is reported as locked.
The information below about how Owner Files work and thier scripted removal is retained for archival purposes.
If a user is actively editing a file, an owner file may be placed on the share in the same folder/location as the file being edited if the user is able to take ownership of the file (It is recommended to avoid this – see section on File Sharing above). This file is uniquely named and marked as a hidden operating system file, so you have to change file options to view Hidden and Show Protected Operating System Files.
These owner files may be called Lock Files or Tilde files. They are in the same folder as the file being edited, and use the same file name as the edited file, except replacing the first two letters of the file name with a ~$
You usually know this is the cause when the warning you receive when opening the file in the Web Client is “DirectLockOwner”
Or a file that otherwise should be editable is reported to be locked and the user cannot edit it. These orphaned owner lock files may be years old, left from legacy systems and even migrated alongside regular files. Beginning with MyWorkDrive server version 6.2.1.7, these orphaned owner lock files are now proactively removed when encountered. For older MyWorkDrive Servers these files will need to be removed by the network administrator.
The most frustrating and hard to track down locked files usually fall to this case – where a user has taken ownership of a file and left behind an owner file. Countless administrators have found owner files after extensively searching other sources – be sure to show hidden and protected OS files when searching your directories!
Administrators have often figured this out by renaming the file which is locked and finding that the renamed file can be edited fine, but when the name is changed back to the original, it again reports as locked. This is because MyWorkDrive is finding a corresponding owner by file name during the open check process and treating the file as locked.
You could rename the original file and create a new file on the directory with the same name as the original, and it would be locked before anyone had ever opened it before! This is a guarantee that an owner file exists and needs to be removed.
This behavior is, in part, a result of MyWorkDrive’s multi-faceated approach to file locking, where we check for existing file locks in addition to whether we can obtain write access to the file to ensure we are never overwriting another user.
Make sure that in your view settings you are showing hidden files and are not hiding protected operating system files.
Browse to the folder on the file server where the user is unable to open the file.
Sort by name and look for files which start with ~$ which replace the first two letters of the file name. The rest of the file name will be visible along with the proper extension. Note these examples –
You may find it difficult to delete the owner file, particularly if the user in question still has the file open. You may find you need to take ownership of it yourself to remove. Using Shares in Computer Management should show you if a user has the file open and facilitate remediation.
Office is generally very good at removing the temporary lock / owner file it places while files are being edited, but its possible older versions of office did not handle the temp files as well. It seems common to find owner files that are older, from the past, say 2015, 2017, 2018. Its also not uncommon for scenarios like backup or replication to place locks on the files that prevented Office from removing them when editing is complete. One client noted that all of the hidden lock files they found came from a period when they were running DFS-R
Scripted Removal of Unwanted Owner Files
The information and scripting to manually remove them is retained below for reference for clients who may wish to remove them manually
Please use the following information at your own risk. MyWorkDrive takes no responsibility for the mis-use of any scripts intended to delete data which result in the unintended loss of information.
If you are experiencing the hidden lock file problem and just want to remove the older ones – we’ve written a script you may use as an example of how to do that.
This powershell script will remove all files in a folder and subfolder that meet the specific criteria:
- File format – ~$file.docx (you can set the file extension to the appropriate file extension)
- File date – to be sure you are not removing current/recent files
- File size – to make sure you are not deleting files that just happen to use the same syntax or which the owner choose to name simliarly.
You can use this script, adjusting the location and dates as appropriate. Use this script at your own discretion. It is intended to delete files from the file system and mis-use could result in unintentional data loss. Backup any file systems you run this on prior to using it, in case of error.
Get-ChildItem -Path “c:\temp\” -Hidden -Recurse | Where-Object { $_.lastwritetime -lt ’01/01/2021′ } | Where-Object { $_.Name -like ‘~$*.Docx’ } | where {$_.Length -lt 5kb} | Remove-Item -Force
It is important that you test this script in your enviornment to ensure compatibility prior to running it on your file share(s).
- Create some simulated temp files that use the syntax of the ownerfile – ~$file.docx, ~$file.xlsx, etc or copy some you find on your file system.
- Adjust the create/modified date with an attibute editor to be an appropriate time period in the past and mark them hidden. Attbribute Changer is an easy one to use
- Modify some of your temp files so they do NOT fit the criteria – don’t adjust their dates; save them with non conforming names or file extensions; add some content, so they are greater than the file size – and validate that only specifically targeted files are affected.
- Run the test on your temp folder and observe that it only deleted files that fit the name, size and date criteria
You may also specify a network path via UNC, ie \\servername\sharename\folder\ , but you may receive an error attempting to use the script with a mapped drive letter
Open file locks in MyWorkDrive, Open Files in Computer Management and an Owner file will resolve 99.9999% of lock file issues.
Other Testing Tools.
These tools exist to troubleshoot more difficult problems which may relate to file permissions and the ability for users to edit files.
Effective Access
Sometimes the issue is a conflict between NTFS and Share Permissions which results in write permissions being blocked through MyWorkDrive. You can test that using Effective Access. This test will show if file share setup is the cause of your file open issue. This usually presents itself as a user being unable to edit any files in an entire folder or directory.
Browse to the share on the MyWorkDrive server and right click on it. From security | advanced choose Effective Access, then choose the user as a principal and click view.
That will tell you what the effective access is, and if that user can access the share on the MyWorkDrive server.
If there is a red X next to the write permissions, the user will be (correctly) told the file is read only as MyWorkDrive will be unable to write it with their credentials. Permissions on the file/folder/share need to be corrected.
In this example, you can see that Share permissions (not NTFS) have blocked this user from having Write access to this folder.
MyWorkDrive File Tests
If you are concerned that a file may not be accessible to MyWorkDrive because of a configuration error, you can test that using the built in File Share testing feature in Shares in the Admin console.
You can confirm if MyWorkDrive can open the file using the test tool in Shares. This will show if any permission issues are preventing a user access to a share, folder or file. This is another good test to run if a user reports they cannot open any files in a particular share or folder.
On the Shares tab in the Admin panel, select the share you wish to test (just click on the share name so the row is highlighted) and then click Test in row above.
On the test screen, you can enter a specific folder or even a specific file if you wish. Or just test the root of the share.
Then either use User/Pass with the user’s credentials or switch to SSO and enter the user’s email (if you use SSO logins and have delegation configured) to test MyWorkDrive access rights.
The test will report if the MyWorkDrive server can access the file/folder or not.
Here’s an example of a test failure. In this case the user does not have permission to write to the share. The Effective Access tests above or an audit of the NTFS permissions will likely yield the cause.
Process Explorer
As a last resort, in the case where files are not shared on Windows File Shares, such as appliances or local disks, a final method to track open files can be used in Process Explorer. This will show you files that are open by processes, services and DLLs.
This is a good way to catch applications like AntiVirus Backup, replication or lock replication applications which lock files at the system level.
Process Explorer is a more advanced task manager available directly from Microsoft
https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
Once you’ve downloaded Process Explorer, run it as Administrator in an elevated session on the MyWorkDrive server.
- Enter the keyboard shortcut Ctrl+F.
Alternatively, click the “Find” menu and select “Find a Handle or DLL”. - A search dialog box will open.
- Type in the name of the locked file or other file of interest.
Partial names are usually sufficient. - Click the button “Search”.
- A list will be generated.
There may be a number of entries. When run from the MyWorkDrive server, you’ll probably be looking for the MyWorkDrive service. Of course, pay attention to other possible blockers as well – Backup, Antivirus, Replication, 3rd party locking etc.
In this example, a user has the MWD Product 2020 docx file open in a MyWorkdrive client. If you noted other processes with that file name open – you would need to track down what and why those are, and they likely have their own locks on the file and are causing users to be unable to open or edit the files.
Alternately, you could search by the service name “MyWorkDrive.Service” and see everything the service has open.
This would be useful to compare to everything MyWorkDrive has open – but it wouldn’t help to see if something was open by something else.
WebDAV
Special WebDAV note: WebDAV is not required and should be disabled from the MWD admin panel when not in use. 3rd party WebDAV clients may not respect file locks (our Mapped Drive, Web and Mobile clients do). If an office file is opened via WebDAV then MyWorkDrive locks write access to the file. MyWorkDrive automatically closes/unlocks files. The application checks WebDAV locks every 15 seconds. If MyWorkDrive doesn’t find active WebDAV locks then the file is closed and unlocked. MyWorkDrive removes locks when a file is closed either through WebDAV or the browser client. WebDAV software can be configured to specify the lock timeout. If no timeout is set or a timeout of greater than 5 minutes is requested, MyWorkDrive changes the timeout to 5 minutes overriding any client settings.
Non-SMB Storage
MyWorkDrive from version 6.4 supports Non-SMB Storage types, including SharePoint, OneDrive, Azure File Shares and Azure Blob Storage
MyWorkDrive does not place SMB Locks on non-SMB Storage, so users accessing files simultaneously with MyWorkDrive users my cause version conflicts or receive access warnings. It is advised when using Non-SMB Storage to exclusively provide access via MyWorkDrive, as the internal locking in MyWorkDrive will ensure file locks are accurately handled across users and enable Co-Editing (when Office Online editing is enabled)
