Database no longer shareable

[PeteHadden]

For years we've used a split front-end / back-end Access DB. Each PC has a copy of the client and the backend data lives on a NAS drive. For some reason recently, once one user opens their client, no other user can access theirs with the message "count not use \\nameofthebackendDB.accdb; file already in use"

I've checked the users have read/write/create privileges (nothings changed anyway) - the first user causes a lock file .laccdb to get created with 0 bytes, and when they close Access the file remains in the backend folder. 

I even tried creating a new database with just a single table and a couple of clients to connect to it and the same thing happens. It also happens when I store the backend on different devices such as a shared folder on a PC. Has something happened to Access or Windows that would cause this behaviour?

[#2]

@PeteHadden  I have exactly the same issue just since this morning. No changes to my setup either.  Just stopped working for everyone.  Only 1 user can use it at a time.

This is our major customer service admin database and 5 users have been getting the benefit of the system for years.  Now a MAJOR problem!

I spent over an hour on to tech support at microsoft and they passed me around until they just directed me here.

Help anyone?

[#3 · Accepted solution]

@Billspark1970 

@PeteHadden 

This appears to be the newest bug released by Microsoft. Information here 

Rolling back this update should resolve it until MS gets a fix out.

[#4]

Here's a detailed rundown and fixes for the following issue. Thank me later :)

Symptoms:
- You receive the following error when opening access "Could not use ‘path to database.accdb’; file already in use"
- Your database backend is stored on a network location.
- The laccdb lock file does not automatically disappear when all users have disconnected from the shared accdb file.

Affected Versions:
- Office 2019 Version 1808, build 10381.20020
- Office LTSC 2021 Version 2108, build 14332.20204
- Current Channel Version 2111, build 14701.20248
- Monthly Enterprise Channel Version 2110, build 14527.20340
- Monthly Enterprise Channel Version 2109, build 14430.20380
- Semi-Annual Enterprise Channel (Preview) Version 2108, build 14326.20692
- Semi-Annual Enterprise Channel Version 2102, build 13801.21086
- Semi-Annual Enterprise Channel Version 2008, build 13127.21842

Caused by:
Microsoft Jet Red Database Engine and Access Connectivity Engine Elevation of Privilege Vulnerability update.

Resolution:
This issue can be resolved one of 3 ways (See below);

1.) Removing the following updates;
- KB5002099
- KB5002104
[Note] This will only temporarily fix the problem until the next time office updates. You can disable the updates in File > Account > Office Updates > Disable Updates

2.) Reverting back to an older version of office by running the following command (elevated)
- Version 2013 – “C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe” /update USER displaylevel=True forceappshutdown=true updatetoversion=15.0.5397.1002"
- Version 2016 – “C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe” /update USER displaylevel=True forceappshutdown=true updatetoversion=16.0.14701.20226"
[Note] This will only temporarily fix the problem until the next time office updates. You can disable the updates in File > Account > Office Updates > Disable Updates

3.) Combination permanent build fix until next build change.
a. Revert back to last update (as seen above).
b. make a copy of the acecore.dll files. You can find these by searching your program files directories.
c. Update Microsoft office as normal using the File > Account > Office Updates > Update Now
d. Once updated, copy the acecore.dll files back into the original locations.

@Billspark1970 

@PeteHadden 

[#5]

@George Hepworth 

Thank you George - I spent a good few hours chasing my tail trying to get to the bottom of that one. It was so recent that there wasn't really anything on the general internet that helped. I followed the instructions from MS on rolling back to an earlier version of office:

https://support.microsoft.com/en-us/topic/how-to-revert-to-an-earlier-version-of-office-2bd5c457-a91...

I settled on version 2111, build 1407.20226 and this works fine. I'm so glad I've only got about 6 PCs to do and not 60! How will we know when MS have released a fix I wonder?

Thanks again - I'm buying you a virtual beer!

[#6]

@PeteHadden MS now has a discussion up on this site. It notes that they'll update it when they get a fix ready. We'll all be keeping  an eye on that page, I think.

[#7]

@NerdyGuy86 

Thank you for the information. I have been working hard over the weekend trying to solve the problem with no luck.

The fact that it is not my database or the network folder configuration made me happy even before solving the problem.

I will go ahead and try the fix and get back to the group.

Again thank you to everyone in this post.

Update:

By uninstalling the update of KB5002104, I could get 5 computer back in business, all computers have Office 2013 Pro. One thing I couldn't understand, one of the computers didn't have this update installed but was not able to link to the back end as well, is that because the other computers already locked the BE out. Does that mean if I still have a computer with this update installed, it can infect the BE if it try to connect to it?

[#8]

@PeteHadden - My users just started getting this message as well.

They are on Build - Microsoft® Access® for Microsoft 365 MSO (Version 2111 Build 16.0.14701.20240) 32-bit & Microsoft® Access® for Microsoft 365 MSO (Version 2111 Build 16.0.14701.20254) 64-bit

Both builds are affected., It was not a split database. When I try to SPlit it, I get could not lock the file.

I am asking the client if they want to Hotseat the database until a fix that actually works is issued by Microsoft, or if they want us to roll back the updates.

According to this "it is fixed (yeah, right) - https://support.microsoft.com/en-us/office/error-in-access-when-opening-a-database-on-a-network-file...

Thanks for your guys's insight, I will update what we find as soon as the client lets me know

[#9]

@cv_Frank - We are on the exact 64 bit build and the issue is persistent on our end. Fix it MS! I may be rolling back tomorrow morning. 

[#10]

Hi,

Today Microsoft has updated the bug article with this caveat:

Note: If you are using Distributed File System Namespaces (DFS Namespaces overview | Microsoft Docs) to redirect a folder that contains an Access database, you will still see the issue that you cannot open the database for shared use, even with the fixed update.
You should use the direct path to the database to allow shared usage.

Servus

Karl

Access News

[#11]

Hi,

Today Microsoft has updated the bug article with this caveat:

Note: If you are using Distributed File System Namespaces (DFS Namespaces overview | Microsoft Docs) to redirect a folder that contains an Access database, you will still see the issue that you cannot open the database for shared use, even with the fixed update.
You should use the direct path to the database to allow shared usage.

Servus

Karl

Access News

[#12]

Hi Karl, so don't use the share name but the full 'UNC' path?

Thanks
Casey

[#13]

We use dfsr but not dfsn so I don't know if this applies to us or not. We just map all our drives via GPO. So it's just UNC path to the servers/shares.

[#14]

@caseyg1760 

It doesn't matter wether you use an UNC path or a mapped drive. What matters is, if the UNC path used (for the mapped drive) is a virtual DFS path. If so, change the path used from the DFS path to a path having one of the member servers of the DFS name space.

If you prefer to roll back to a previous version not hit by this issue, I've found it to be this (or earlier):

Version 2102 (Build 13801.21050 Click and run) semi-annual enterprise

[#15]

@Gustav Brock 

As I'm not familiar with the server structure and all this terminology, I won't update office for the time being until this bug is completely gone. It safer that way (at least for myself).

Happy holidays guys and thank you for all your help.

[#16]

It seems that Microsoft believes this was fixed in version Version 2102 (Build 13801.21092), but we continue to experience the problem and have had to roll back to Version 2102 (Build 13801.21050). Is anyone else still having this issue?

I'm trying group policy to deny the 21092 version and force the 21050 version and have manually rolled the workstations back.

[#17]

Microsoft has updated the doc and now says:

Important: Currently, the applied fix only addresses standard UNC paths. Our team is currently working on a fix for the following network paths:

• DFS-N

• Short file names

• Mapped drives

• Hard links, Junctions and Symbolic links

[#18]

The sharing issue with MS Access database is solved today after Microsoft has published the newly update (KB5009545).

@scottchester 

[#19]

Hi,

Since the discussion here has been read by many people with all kinds of versions and networks, I'd rather repeat the ~3/4 all-clear in more detail:

Read the support article carefully, especially if you have reverted to an older Office build or uninstalled or disabled updates because of the bug!

According to the article and most reactions in forums etc. Microsoft fixed the bug for most Office versions and variants last week. However, this has not yet been completely done for:

• Office 2013
• Office 2016 MSI
• Microsoft 365 Apps Semi-Annual Enterprise Channel Extended

For these versions, the bug was only fixed for direct network paths, not for DFS namespaces, short file names, mapped drives etc. If you are not sure what is used on your network, check with your system administrator.

Microsoft will update the article when these versions are also completely fixed. However, there is no time forecast for this yet.

Servus
Karl
************
Access News
Access DevCon