This is a permissions problem. Specifics will be tricky, but maybe I can point the right way. Here is a link that will go deeper than I can.
Learn about access control in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer.
learn.microsoft.com
This link gives examples:
If a Windows object does not have a discretionary access control list (DACL), the system allows everyone full access to it.
learn.microsoft.com
First, one would hope that this is a split database with individual front-end files for each user and the common back-end file that is shared.
Next, on ALL machines - ones that work fine and ones that don't - you need to know permissions for TWO files... the .ACCDB/.MDB file that is being shared and the folder that holds it. For each file, this determination is done starting with a right click >>Properties >> Security - which gets you to the Security control that has multiple parts. You will be comparing these settings. Stay with me on this description.
In the Security control panel, you will see a list of all "security identifiers" that have some kind of permission to use the file that you right-clicked. This list will include entries such as:
"Authenticated Users" (i.e. anyone validly logged in to that machine)
"SYSTEM" (windows internal code)
"Owner" which will be followed by "(machine name / username of the owner)"
"username (machine name / username )" - probably the name of the person logged in
"Administrators (machine name / Adminstrators)"
"Users (machine name/Users)"
- and you might have other possible entries like "Backup Operator" - but those I listed are the most common.
You will not usually have trouble with "Authenticated Users", "SYSTEM", "Owner", "Administrators", and "Users". Of these, "Authenticated Users", "Administrators", "Owner", and "Users" are pre-defined user or group identifiers that are generic in nature. SYSTEM is specifically any internal Windows code that has to run in user context. NOTE ALSO: If your site implements non-default (i.e. manually created) user groups, one or more of those groups CAN show up in the list - but might not show up everywhere, unlike the ones I listed earlier. On the other hand, if they are present, they follow the same rules as any other entry. FYI, that list of names is a literal readout of something that Windows calls an "Access Control List" or a "Discretionary Access Control List." The individual names are "Access Control Entries". If you need to look up more about them, use those names in your search.
Below that user/group list is a list of permission CATEGORIES (think of them as macro groups for the 14 known individual permissions.) One of the user name/group names will be highlighted/selected and the permission categories you see are for that selected user/group, with check-marks to show which ones are permitted and which ones are not. (Also watch out for DENY checkmarks!)
OK, here are some factors to consider. FIRST, when reading that list, it is a top-down list and ORDER IS IMPORTANT. If you qualify as a member of one of the pre-defined groups AND that group appears before (above) your username, then that group's permissions are used even if your name appears later in the list! FIRST MATCH WINS!!!
If you are in doubt, use the Advanced option in the Security Dialog box, take the Tab for Effective Permissions, and in that tab, pick a username - yours, for example. You will see the results of evaluating the access control list and this includes applying the list IN ORDER.
Of the permission categories, if you want to use Access, both the .ACCDB/.MDB file and the folder that contains it MUST have at least MODIFY permissions. MODIFY implies READ, WRITE, READ ATTRIBUTES, and a couple of other things for the DB file and ALSO implies CREATE and DELETE when working in the folder. YOU MUST HAVE MODIFY on both the DB file and its containing folder. The inability to delete a lock file indicates one of two situations - (a) file still open somewhere or (b) user attempting to delete it doesn't have permission to do so.
Now, the OTHER thing to consider. That "isolationist" locking MIGHT be from a DB setting. Check the front-end file that you distribute to your users to assure that in File >> Options >> Client Settings, scroll to "Advanced" and assure that the file is set to open shared rather than exclusive. But then the permissions can kick in here, too. IF a user CAN open the DB file but cannot CREATE the lock file (as would occur if the folder permissions were wrong), Access goes into a defensive posture that does an exclusive-open on the file.
Now, a note about users. A username is not really just, for example, "FRED". If FRED runs on the XDEPT003 machine, his login name (if locally managed) would be XDEPT003/FRED. IF FRED logis in to the ALLDEPT domain then his name might be ALLDEPT/FRED. The names that appear in the Access Control List will tell you where that person's account is defined because the machine name appearing in THAT list is where that user's account information is stored. This matters only in this sense: If XDEPT003/FRED or ALLDEPT/FRED is a username that Windows can verify, then FRED is an Authenticated User, and the order of ACL entries (ACEs) is significant if the desired permissions for FRED are different from the permissions found in the Authenticated Users list.
Normally you have to be a systems admin to change the order of an Access Control List. The CMD-prompt utility named ICACLS can manipulate the access control entry on a file but ALSO requires admin privileges.
It has been eight years and therefore I don't immediately recall the method we used to re-order ACL entries but there is a general rule about those entries. You want them to be in the order: Specfic Deny first, then Specific Allow, then General Deny, then General Allow. And watch out for those DENY cases because there is a rule that says "One DENY cancels a thousand ALLOWs."
