For your #1 question but taking part of #2 into account:
If the idea is to have a shared back-end (BE) MDB that everyone will use and a separate MDB front-end (FE) file that evenyone can copy, then it is fairly easy to implement as long as your network will support the operation.
The issue with network access to a common BE is that you have to use the linked table manager to identify the locations of your tables. You have a choice here, and one is more reliable than the other. Your easier method is to use drive letters - but if even ONE of your potential user base has your chosen drive letter in use for another app, then you have to move the drive letters for everyone. BUT if you use UNC mapping (which has \\server\share-name\folder\child-folder\...\database.MDB format), then you never use a drive letter and Windows doesn't have a problem with a UNC reference.
Still addressing #1, don't forget that if you use external software (such as Excel or Word) from access, your references all have to be managed the same way. But there is one last "gotcha" to consider. Starting with Ofc2007, you had the OPTION to install either the 32-bit or the 64-bit versions of Office. You can tell by opening a database, then from the File Tab, Click HELP and look at what it says under "About Microsoft Access." It will include either "32-bit" or "64-bit" in its description of the version of Access that was loaded to the machine. So... on cases that don't work, see if you have the right "flavor" of Office loaded.
Given the error you have reported, my bet is that on the miscreant machines, either the drive is not mapped or is mapped to another location.
Note that if this is NOT a split FE/BE database, then your problem is more complex - but if you haven't split the database but still intend to share it, my best advice is to split now and save yourself the headache / heartache / butt-ache later.
If you have a network that has a reasonably reliable login, then your #2 question is not so hard, but the design of your database will torpedo you to tears if you were careless. For ANY shared FE file, you should always have an Opening Form declared to act as your switchboard or dispatcher or master operations control form, where you click on a button to bring up the functions that others will use. Then, your switchbaord can have code in it to use the Environ("Username") function to determine the login name of the user trying to open the form. For shared database, NEVER let your users see the Navigation panel or the ribbon. ALWAYS force them to use command buttons or other clickable controls to launch whatever they need to launch, even if it means making a LOT of buttons.
You can also find articles on the topic of "securing" shared databases and "hardening" shared databases. These would also be good places to look at issues requiring study.
If you have a table that has user's network login names as its primary key, you can put your information on user roles or rights or privileges or whatever in that table - which then gives you the chance to enumerate what each user can do. Use the search function of this forum for what must be a few hundred (or by now, a few thousand) posts on the subject of "User-level security" and "User roles" and similar keywords. Your switchboard, being the first thing the user sees, can act as your "junk-yard dog" that will reach up and bite anyone who shouldn't be there.
Another alternative that might be more complex to set up but easier to maintain is that you can develop some security code that would be callable from any form's class module in the Form_Open routine (which allows a CANCEL option to prevent the form from opening). Using the FE/BE split structure, you put a general module in the FE that has Public variables you will load from the switchboard form and that can be tested from other forms, That way, each form could decide for itself whether user X has the required role, rights, privileges, or whatever, and could then act accordingly - OR the switchboard could just ignore the button clicks for the forbidden functions. OR you could even disable the buttons (Set the .ENABLED property to FALSE) that are forbidden, which will have the effect of "graying out" what a user can't do.
Doing this via the general module as both subroutine source and data variables storage as I just described would eliminate having to requery the user information tables for every form, not that such a requery would take that much time.
The way I did this on my most ambitious project was to include a call to the (general module) code that looked up the current user and loaded the public variables that defined user abilities. Each form called the same code - but the code checked to see whether the information had been stored in the public variables already. If not, then it loaded them - but if the variables were not empty, then it just skipped to the end of the subroutine. This allowed me to run the forms in my test environment outside of the switchboard but then when in the shared environment, I didn't end up "re-inventing the wheel" for every form that got opened.
Which brings up the subject that if you want to share your app, look up the subject of splitting a database and in particular look at discussions on "design master" copies of what you publish to the world.
