This problem can be exacerbated by some users not having proper access rights. All users who run Access on this shared .MDB file absolutely MUST have certain rights to the directory. If they do not, you run the risk of this situation.
Users must be able to do : File Scan, File Read, File Create, File Delete, File Update, and File Write. Depending on the nature of your file server, these ability names may differ from what I listed.
You need Scan to identify files.
You need Read to read the .MDB and .LDB (if the latter exists)
You need Create if you are the first person to open the .MDB because YOU have to create the .LDB file.
You need Delete if you are the last person to close the .MDB because YOU have to delete the .LDB file.
You need Update to be able to modify the contents of the .LDB file once it is open and you start actions that imply locking.
You need Write to be able to fill in the contents of the .LDB file if you are the first creator of it.
Of course, Access itself will do these things for you, but in network security terms, Access "rides" your own privileges. That is, Access is not defined to run as Admin. It gets its rights from your individual rights profile. Which is why ALL of your users need this set of rights. And it does not matter whether they are "read-only" to the database. They will NOT be read-only to the .LDB file.
Now, this relates to your problem if someone is UNABLE to delete the .LDB file when they exit out of Access. So before you rattle the saber over their heads, verify that they have rights to do what is necessary in that directory. If they do, THEN go ahead with the saber rattling. Then, it will be deserved.