Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, December 19, 2016 6:46 AM
Howdy,
I am having problems attaching a network drive under elevated command prompt.
I want my elevated processes to be able to work with a network drive. To ensure this access, I want to attach the network drive under an elevated command prompt. However, when I do that, I get the System error 53: The network path was not found error.
At the same time the same drive is attached non-elevated and is fully available for read and write operation under non-elevated processes.
Local computer (where I want to create the network drive): Windows 7
Remote machine (where the network shared resource is located): Windows 10
User account used to attach the network drives: a local user account, which is a member of local Administrators group on the remote Windows 10 computer.
Not only the remote Windows 10 machine is reachable and ping is OK, but the network UNC path can be opened from the Windows 7 machine and network drive X: is bound to this remote path and accessible for the non-elevated processes on the Windows 7 machine.
Could somebody please give a clue on what could be the problem?
Thank you.
Well this is the world we live in And these are the hands we're given...
All replies (3)
Monday, December 19, 2016 7:17 AM
Okay, the error is not related to pure networking. Instead it is related to user account impersonation. For some reason, running elevated command prompt under a remote user is not a solution. So this does not work:
runas /user:windows10pc\user /netonly cmd
Because
whoami
returns
windows7pc\user
and not
windows10pc\user
The workaround I've used:
1) On the local Windows 7 computer open Vault.
2) Add the credentials for the \windows10pc and user on that computer.
3) Open elevated command prompt on Windows 7 computer and type:
net use x: \windows10pc\folder /persistent:yes
The issue that is caused by elevation: while under non-elevated command prompt you are asked to provide user credentials to access remote windows10pc when typing 'net use', under elevated command prompt you are not asked for the credentials. As a result, elevated command prompt always attempts to access the remote network resource by using the credentials for the local user on Windows7pc.
I would appreciate if somebody could hint a better solution.
Thank you.
Well this is the world we live in And these are the hands we're given...
Monday, December 19, 2016 4:57 PM
I would appreciate if somebody could hint a better solution.
Have you looked at PowerShell PSSessions? ; )
Oh. Maybe you could just use Invoke-Command instead
(or man about_PSSessions -ShowWindow)
<quote>
If you use the ComputerName parameter of the Invoke-Command or Enter-PSSession cmdlet to run a remote command or to start an interactive session, Windows PowerShell creates a temporary session on the remote computer and closes the session as soon as the command is complete or as soon as the interactive session ends. You cannot control these temporary sessions, and you cannot use them for more than a single command or a single interactive session.
</quote>
Just an idea. I'm not sure where it might lead for you.
Good luck
Robert Aldwinckle
Monday, December 19, 2016 5:08 PM
Thanks, Robert. That would be helpful when making temporary connections. Not for this specific case, but still a good thing to look at in the future.
For this specific case I wanted my Windows7pc to always have attached a network drive that maps to a remote network folder located on a Windows10pc. Simply using net use /persistent:yes resulted in Windows7pc being unable to attach the network drive after a restart. It looks like connection credentials are not stored anywhere although mapping is persistent.
I thought creating an account on the Windows7pc that has the same name-password pair as the local account on the remote Windows10pc would help, but it didn't. After every restart of Windows7pc computer Windows was unable to map the network drive due to access issues.
Well this is the world we live in And these are the hands we're given...