Accessing Windows 7 OS shares at the C: drive level
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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\admin
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\admin
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."
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\admin
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\admin
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."
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.
Buit you can (official MS workaround) this by using the ip with one set of creds and the name with the other.
ASKER
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.
But, I must confess that I don't understand the rest of what you said or the error message.
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\admin
versus
net use \\IPOfremotepc\c$ passwdOfAdministrator /user:rIPOfremotepc\admini
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\admin
versus
net use \\IPOfremotepc\c$ passwdOfAdministrator /user:rIPOfremotepc\admini
ASKER
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:
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.
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.
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.
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.
ASKER
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...
"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...
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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$.
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$.
ASKER
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!
Good insights here!
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.