Accessing Windows 7 OS shares at the C: drive level

Fred Marshall
Fred Marshall used Ask the Experts™
on
As background:
I KNOW that sharing the OS root drive C: isn't recommended.  I don't recommend it myself.  And, I have some good suggestions how to avoid doing so.  But, there are times when it has to be done - which I don't need to discuss here.  There are certainly times when a system is set up this way and *must* be maintained as-is.

Also as background:
The environment is a workgroup and sometimes a subnet-to-subnet situation without inter-subnet name service (so IP addresses are used instead in that case).  But here we can focus on sharing in the workgroup.  And "require a password" for sharing is turned off on all the computers.  XP peer-to-peer simple sharing is the model really.  On the XP machines involved here, Simple File Sharing is enabled.

And NOTE WELL: This is ONLY about sharing at the C: drive level.  Any subfolders within are already easily enough shared.

That said:
I have not been able to reliably share the OS C: drive.  Sometimes it works and sometimes it doesn't.  I have attached a file which I hope is self-explanatory.  It shows two clients (one XP Pro and one Windows 7 Pro) which try to see into the shared C: drive of a Windows 7 Pro machine - with a variety of User/Passwords/Logons.  That is, if a logon is shown then that's the one that was used for that trial AND that User/PW does exist on the machine whether logged in or not for that machine.

Since passwords aren't supposed to be required:
- I'm a little surprised that they do seem to matter.  
- I'm a little suprised that a login dialog appeared in one case

Also, it appears that they are *remembered*.  If so, there must be a place where they are stored.  Maybe it's not essential to be able to see them but it seems important to know how this works.

This is a general question about "how does an administrator deal with Windows share folders at the drive level?" and "how can one make such shares work reliably?"  It's not about "try this" and "try that" although I'm more than willing to run experiments such as in the attached table.  

I want to *understand* so I can develop an approach that always works.
Logon-scenarios.pdf
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2012

Commented:
Fmarshall, we are always glad to help but it may really aid the troubleshooting process if you could let us know why this "has to be done."

To be perfectly honest, I have been working within the IT industry for almost 30 years and I have yet to see a truly compelling reason why someone would potentially need to share out the entire operating system partition.
Distinguished Expert 2018
Commented:
Hi.

Are you using the administrative share c$ (which is already existant by default)? I don't see why connecting to c$ by using the net use command in combination with an administratíve account should not work.
net use \\remotepc\c$ /user:remotecomputer\administrator passwdOfAdministrator
If you use explorer, you will use the guest account which may not access c$. Why the guest? Because you have simple file sharing enabled, aka "forceguest".

Author

Commented:
Run5k:  Because, after getting good advice like yours and mine, "the folks issuing the paychecks say so" is a pretty good reason.

McKnife:  OK, good suggestion it seems.  And this may well circumvent the apparent "need".

I'm a little unclear on the syntax:

net use \\remotepc\c$ /user:remotecomputer\administrator passwdOfAdministrator

At:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/net_use.mspx?mfr=true
I have seen:

net use \\remotepc\c$ passwdOfAdministrator
/user:remotecomputer\administratorname

 In my cases I've not been able to make this work either way unless the user is Administrator and in that case I don't need a password at all (they are common).

For example, I have a user defined on both computers that is an Administrator.
And, that user is not logged on on either computer.
Using that user name with password gives the error:

"Multiple connections to a server or shared resource by the same user, using more
 than one user name, are not allowed. Disconnect all previous connections to the
 server or shared resource and try again."
How to Generate Services Revenue the Easiest Way

This Tuesday! Learn key insights about modern cyber protection services & gain practical strategies to skyrocket business:

- What it takes to build a cloud service portfolio
- How to determine which services will help your unique business grow
- Various use-cases and examples

Distinguished Expert 2018

Commented:
You have not been able to make it work unless admin because you have previously tried it with other credentials (of the logged on user, for ewample). Windows does not support different sets of credentials to connect to one and the same server.
Buit you can (official MS workaround) this by using the ip with one set of creds and the name with the other.

Author

Commented:
Yes, I've read that and done it in that latter manner with the IP address.

But, I must confess that I don't understand the rest of what you said or the error message.
Distinguished Expert 2018

Commented:
Sorry for all the typos in my last comment.
I tried to explain that in order to work around that error message, you will need to use the ip-address together with the net use command. If you already have used the ip-address, you will have to use the name of the remote server.
net use \\remotepc\c$ passwdOfAdministrator /user:remotecomputer\administratorname
versus
net use \\IPOfremotepc\c$ passwdOfAdministrator /user:rIPOfremotepc\administratorname

Author

Commented:
OK.  I used the latter successfully - which is what I'd tried to say.
Using the former didn't work.

What I'm trying to figure out now is what the issue is....
Who is doing what and with which and to whom?

As above:

 
In my cases I've not been able to make this work either way unless the user is Administrator and in that case I don't need a password at all (they are common).

For example, I have a user defined on both computers that is an Administrator.
And, that user is not logged on on either computer.
Using that user name with password gives the error:

"Multiple connections to a server or shared resource by the same user, using more
 than one user name, are not allowed. Disconnect all previous connections to the
 server or shared resource and try again."

To elaborate:
I've not used the admin shares C$ before.  I'm trying to understand how this works and why there would be errors.  (I can hardly recommend an approach until I understand it myself).  So I *think* the question is around:
"why do some share logins work and others don't?"
And, perhaps particularly, why doesn't the 2nd user defined on both systems not work?
Or, why does Administrator work?
etc.
That's where I'm unclear...  Sorry to be so dense.
Distinguished Expert 2018

Commented:
The administrative share c$ is there by default. The share permissions cannot be altered and only administrators may access it. That's one thing to understand. The other is that you cannot have two connections two one server (or workstation that shares folders) with different credentials.  That's because windows uses these credentials to connect to other shares afterwards, too. Example: You connect to share \\remotepc\myshare using user youruser. Afterwards you try to access \\remotepc\share2 - automatically windows tries to use the credentials of user "youruser". If those credentials don't work on that share because permissions of share2 are more restricted than perms on myshare, you cannot simply go and take a different set of credentials. No, windows quits the try with the error you quoted although it seems a perfectly normal idea to try different creds and you entered them correctly and they would entitle you to access that share.
No, MS' design wants you to use the workaround with the IP to use a different set of credentials.

Now to the question why you used weak credentials in the first place, maybe without even knowing it: with simple file sharing enabled at the client side, windows automatically sends the guest credentials! It does so even if you have not yet entered a share, so even if you browse network neighborhood and open that remotepc it does.

Author

Commented:
Please feel free to comment liberally as I'm still a bit in the darK.  I've started reading about related aspects of Windows file sharing but there appears to be precious little information on "HOW does it work?"  mostly just setup instructions for specific situations.

"You cannot have two connections to one server (or workstation that shares folders) with different credentials."

So, I take it this means something like this:

1) "server workstation 1" has Users: Joe, Sam and Sally with password.  All are Administrators.
Joe is logged in (or does this matter than anyone is logged in?)
There are various shares of lower level folders set up and no passwords are defined for these shares.
Simple file sharing is enabled in the case of XP (what about Win 7?).

2) "workstation 2"has User Mike with a password defined.
"workstation 2" sees the shares of "server workstation 1" in My Network places.

3) "workstation 2" tries to open one of the shares on "server workstation 1".
If it's a "normal" (not a drive level) share then it works.

4) "workstation 3"... different user/password there ... does the same thing successfully.

So, I presume from what you've said is this:

a) there must be common credentials to satisfy the initial assertion above.

b) those credentials, to be the same, are "guest credentials".  
What the heck are those??

5) If the C: drive has been shared in the same way on "server workstation 1" then:

a) "workstation 2" can see into them.
b) "workstation 3" can't see into them.
c) using net use .... there are certain credentials which must be used.
What are they?


"Windows uses these credentials to connect to other shares afterwards, too."

Do you mean from the client side or the host side that these credentials reside.

"Example:
You connect to share \\remotepc\myshare using user youruser."

"Afterwards you try to access \\remotepc\share2 - automatically windows tries to use the credentials of user "youruser"

So, somewhere the original "successful" credentials resides and they are reused?  Where?

"If those credentials don't work on that share because permissions of share2 are more restricted than permissions on myshare, you cannot simply go and take a different set of credentials."

Well, yes, I wouln't know how to do that anyway unless using "net use".

"No, windows quits the try with the error you quoted although it seems a perfectly normal idea to try different creds and you entered them correctly and they would entitle you to access that share.
No, MS' design wants you to use the workaround with the IP to use a different set of credentials."

OK.  I can accept that whether I like it or understand the implications of it or not.

"Now to the question why you used weak credentials in the first place, maybe without even knowing it:

"With simple file sharing enabled at the client side, windows automatically send the guest credentials!
It does so even if you have not yet entered a share, so even if you browse network neighborhood and open that remotepc it does."

From this I get that the guest credentials come from the server workstation.  So that's why browsing network neighborhood works and one can see into the shared folders...
I believe @McKnife has the right idea.  

Here was something similar but different, related to understanding the connection credentials (see my comment/answer, essentially whichever one is first is the credential you're stuck with for the session, it might not have the permissions you need for other connections to/from same file-server(s)/client pairing(s), one credential per pair (two if/when IP workaround works)) http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/Windows_7/Q_27018152.html
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_26698996.html

Using command-line net use is infinitely easier than the GUI.  Make sure you're running said command-line shell "As Administrator" too.

Author

Commented:
ocanada_techguy:
Those links were very helpful.  Now I can *see* what's set up and that reveals quite a bit of insight.

Now it looks like I can get back to my original question:

I've learned that there are good ways to access the C$, etc. shares.  That's very useful by itself.

Now I want to make sure that I know how to do the hideous (reliably):

Share the C: drive and access it without using C$.

Author

Commented:
I may have the answer to the original question but I'm going to have to research and try things a bit more.

Good insights here!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial