Try first running the compact/repair. (ie. Tools -> Database Utilities -> Compact and Repair.
Close out of the mdb completely (frontend/backend). Look in the folder and see if there is an *.ldb file. If there is (backend and/or frontend), then someone still has the mdb file open (ie. they may be logged into their workstation (ie. it's locked-workstation) and still have it open.) You can use the utility in the code bank to find who's using the mdb file (I think it's called JetModUtil or something but it's in the code-bank.) If you're absolutely sure no one is in the mdb, you're admin folks should be able to do a "hard" delete against the *ldb file and then you can compact/repair immediately after they remove it. *.ldb files though usually go away (if no one is in it), by simply opening the mdb, running a compact/repair, and then closing the mdb file (you should no longer see an *.ldb file then.) If you see an *.ldb file on the backend mdb file, keep in mind that the tables could be linked to other front-ends that are open. You'll need to have EVERYONE who has an mdb file open which has tables linked to the backend, close out of their frontend! (getting rid of the hanging *.ldb file is first.) Usually you can't delete this file is someone is accessing the mdb file in some way.
Your problem though sounds like a network connection/configuration issue. Try putting both the front-end/backend (and the mdw file) on your local drive. Modify the shortcut file to the mdb (you'll need to create one if you don't have a shortcut or simply first try it without the mdw parameter (ie. just click on the mdb) and see if that works.) If you use the mdw file, make sure to put in the correct parameters for the mdw location (see help for mdw shortcuts for what it should like.)
If your mdw file is corrupt/missing and there's nothing you can do without it (ie. import/export into new mdb files), you'll need to find it! Then modify your shortcut's properties to point to the correct location of the mdw file in the parameters of the shortcut. Finding the mdw file is key if MSAccess security was implemented (you may need to locate a backup of it somewhere.) Then make sure the properties of the shortcut again, point to the correct mdw file. It's extremely difficult to hack an mdb without an mdw IF permissions were implemented that way.
If you can't locate a good mdw file, you'll need to create one and then hopefully be able to assign permissions (this is difficult to do if it it's even possible - keep your fingers crossed here.) You can also just try opening the mdb without the mdw file and see if that works as it may simply be a connection issue (if you're not sure if mdw security was implemented.) - again, hopefully the mdw file won't give you problems and wasn't really implemented.
You can also use the MDWSecurity hacking file (it's called: UPVMSA2K.MDA and I uploaded it below.) You can use this on the mdw file to see who has permissions in the mdw file (along with their passwords.) - if you've found it!
Other than that, you'll most likely need to look at your backups or just create new mdb's (1 for frontend and 1 for backend) and start importing objects and then re-linking the tables.
I might try relinking the tables first or importing them into a new mdb and then link them into your frontend (avoiding MSAccess security). If you can do that and don't get stopped by MSAccess security not allowing you permissions, then you're in good shape. You just have to link the tables correctly and should be able to open the mdb file without an mdw as a parameter (unless you then want to re-implement security which I wouldn't advise). MDW files are a pain to work with and it's often easier to just implement your own kind of security within the application.
Remember that what might be the G: drive on one of your work computers, could be the F: or another drive on a different computer so you need to make sure you find a good solid location for both your frontend and backend that works for everyone. I'd first try everything on your c: drive. Then copy to a network drive and relink (and re-implement the shortcut to the mdw file if need be which should also be on the network drive (I keep them in the same location.))
Good luck - hope this helps.
Notes (the 3 files you're probably dealing with):
1. XXXXX_BE.mdb (this is usually your backend file)
2. XXXXX_FE.mdb (this is usually your frontend file that you directly open if you're not using an mdw security file)
3. XXXXX.mdw (this is the security file). If your mdb is protected with this security file, you'll need to open this shortcut to the mdb using the correct parameters which has the location of the mdw file in it. Use the utility below on the mdw file if you need to find a login/password that lets you do everything. I would immediately start exporting the objects into a new mdb (and get mdw out of the picture and possibly re-implement mdw security at a later time after everything is running and in it's right location.)
4. XXXXX.ldb (when someone opens the mdb file, MSAccess automatically creates an *.ldb file associated with that mdb file (so you would see one for the frontend and one for the backend.) If you close the frontend and still see an *.ldb file for the backend, someone else has an mdb which has tables linked from that backend.) Get everyone closed out first! Run the compact and repair. If *.ldb file still exists, do a "hard" delete by the admin people (they usually have special permissions to rid files like these.) Then make sure you compact/repair immediately after. Then start doing copy/paste to make backups!! If everything goes ok so far and the mdw security hasn't stopped you, start importing all your objects into a new mdb (which won't originally have mdw security on it.) Hopefully that will work.
*.ldb files are basically "tracking of who's using the mdb file" type of files. They easily get corrupt if someone loses their network connection or has a poor network connection or keeps the file open and minimized for 4-5 hours (where the *.ldb gets confused if the user is still using it.) This also causes problems for others. Especially if a person has a record open on a form and it's been open for 4 hours without any activity. Of course, if the mdb forms are designed incorrectly (ie. many, many subforms which conflict with other subform tables, recordsets not closing in code, etc...etc..), you may have to look at a re-design. MSAccess has a 3-5 multi-user limitation mainly due to this *.ldb file (like a Word document, you can't have 5 users editing that word document at the same time and it could easily get destroyed with users opening/closing/sitting in it.) There are things you can do to avoid this and prevent the "Locked by another user" error though - see the VB
Cloning script in the code bank. This works very well for solving this problem. - I use it all the time and have never had the "Locked by another user error." (even with 100 users!!)