Paul's Site of Stuff ^..^

After migrating a client's file server from Windows to a FreeBSD samba share, they have noticed some files when opened are not prompting other users to open the file in "Read-Only" mode. The additional users can just open the file with read+write permissions.

This should not be!

Searching the internet gives a handful or results, often met with Microsoft's "Run these powershell commands blindly and you'll be sorted" support method - which are basically no help at all.

The Situation

Excel files, when opened, should create a lock file to prevent other users accessing the same file. When this lock file is in place, whenever another user opens a file that is already open they should see a prompt telling them the file is locked, and asking if they would like to open the file in Read-Only mode, allowing them to view the contents but not edit the file.

However, after the migration from a Windows 2008 file server to a FreeBSD samba share these file locks seemingly expire, another user can open the file and change it as they need, risking conflicts.

The users have noticed that if Person A opens a file at 8am in the morning, leaving it open all day, when Person B opens the same file at 2pm in the afternoon they are not prompted that the file is already open, and they can edit the file as they wish. When Person A goes to close and save the file later in the day they are unable to because they do not have a lock on the file. Their only option is to save the file as something else and copy it back over the original. It's clear to see here that if Person B made any changes, they will be overwritten when Person A housekeeps the files.

What's going on then?

This started happening after a server migration from a Windows 2012 server to as FreeBSD server running Samba. Although the client isn't interested in the actual details, nor that it's FreeBSD as opposed to Windows, it is reasonable to expect them to ask whether the new server is the cause here; everything was "fine" before after all.
But, this is not my first FreeBSD file server, and certainly not my first Windows to Samba file migration. No, it is definitely not the new server at fault here.

Trying a web search for "Excel file locks expiring" in 2026 is next to impossible. First you get a load of results explaining what file locks are, and the Microsoft support articles in question just tell you to run some powershell commandlets to configure the file shares which are no good because:

1. the commandlets aren't actually going anything just disabling SMBv1 and enabling OpLocks, both of which are default anyway now, and
2. it's not a Windows file share.

I tried to look for some samba specific idle/timeout settings, which do exist, but I feel the defaults are reasonable so decided it isn't worth continuing this route of troubleshooting.

Eventually, I found one reddit thread that pretty much explains and answers the problem in the first comment

GPO Drive Map Policies

GPO (Group Policy Object) is a Windows technology that allows for configurations to be deployed to all domain-joined computers in the network. One such configuration is to map shared folders to "drives". If you've ever worked in a Windows based office environment you've seen it - you've had an "S" drive that maps to the network-wide file share.

A GPO drive map has a number of options, Create, Replace, Update, and Delete.
The first two are straight-forward:
"Create" creates a new drive for users if one does not exist.
"Delete" deletes a drive map if it exists.

"Replace" and "Update" however are a little more complicated.
"Replace" deletes a drive if it exists and then creates it. If the drive doesn't exist it just creates it.
"Update" modifies a drive if it exists or creates it if not.

It's important to be familiar with the difference:
Replace = delete AND create
Update = modify OR create

In my experience, "Update" doesn't work too well when changing from one server to another, but using "Replace" enforces the switchover to the new server promptly... which is great, but this is actually where the problems are caused.

Replace = Delete AND Create

To get back on track, the client were noticing the file lock expiry happens after a few hours, and it just so happens Group Policies tend to be refreshed periodically through the day too. Guess what! This means the replace action gets triggered every few hours too!

What that means for Excel is effectively it's link to the file share is removed and even though the file share itself reconnects, Excel's hold on the lock file is lost. The file lock becomes stale, and is lost. Other people are now free to open that file up in read+write mode.

So... um... yeah. Kinda my fault. As soon as I was satisfied all PCs had re-mapped to the new server drive path, I should have changed the "Replace" action to "Update". Or, I should have set up the GPO to only apply the Replace action once.
Lesson learned.

Anyway, with that now changed we wait and see. Computers will update their policies through the day and we should be good.

TL:DR;

If the files losing their file locks are on a mapped drive provided by a Group Policy Object: check that GPO is setting the mapping action to "Replace" and change it to "Update" on all domain controllers.