Okay, crash course Windows shares:
Yes, you'll always need a shared folder to access files on a remote system via SMB (the protocol used for that kind of access):
net.MapNetworkDrive "Z:", "\\SERVER\SHARE"
However, you don't necessarily have to share the particular folder (although that's recommended in most cases), but can also map
subfolders of the shared folder:
net.MapNetworkDrive "Z:", "\\SERVER\SHARE\SOME\SUB\FOLDER"
On top of that Windows systems by default share the root directories of all local drives, so you can do stuff like this:
net.MapNetworkDrive "Z:", "\\SERVER\C$"
These are the so-called "administrative shares". And of course mapping subfolders also works for administrative shares:
net.MapNetworkDrive "Z:", "\\192.168.1.3\C$\test"
As long as there's a folder "C:\test" on the computer with the IP address 192.168.1.3, that is.
Access to administrative shares is restricted to members of the local administrators group on the remote system, though, so you must provide the credentials of an admin account on 192.168.1.3:
net.MapNetworkDrive "Z:", "\\192.168.1.3\C$\test", , "adminuser", "password"
In a workgroup you must either maintain identical usernames and passwords on all systems (in that case Windows should automatically use the credentials of your current user for mapping the share), or you have to explicitly provide the credentials of the remote user. In a domain, the "Domain Admins" group is by default a member of the local administrators group on every domain member (the group is automatically added when you join a computer to a domain). The centralized user administration in a domain saves you the headache of maintaining local users and passwords on all systems.
If the two computers are members of different domains, you must provide the username including the domain name:
net.MapNetworkDrive "Z:", "\\192.168.1.3\C$\test", , "EXAMPLE\adminuser", "password"
or
net.MapNetworkDrive "Z:", "\\192.168.1.3\C$\test", , "adminuser@example.org", "password"
If you have the correct username and password, but access still fails, there are several reasons that may cause this:
- The Windows firewall is blocking access: add an exception.
- Someone had disabled the administrative shares: check with "net share" and re-enable the shares by changing the respective registry value and starting the Server service.
- Incorrect permissions to the share: best practice is to grant full access to Everyone, because unlike filesystem permissions share permissions affect only the share itself, not its subfolders. Plus, filesystem permissions are far more fine-grained anyway.
- Incorrect permissions on a folder: check and correct the permissions on the folder.
There are also other ways to access remote files (like WMI), but I wouldn't recommend them, since they're more complicated and you'd still need to provide credentials.