dchunt Absent Member.
Absent Member.
1574 views

Can't access map rooted drive letter from cmd prompt

We are trying to move files from an OES server to an AD server. In the process, we have run into files that appear to have file names that are too long to copy, giving us an ERROR 123 in Robocopy. So I map rooted a drive letter to a point farther down the path so that the file name would be shorter. However, when copying using robocopy from the map root, I still get the same errors.

BTW, it looks like, on Windows 7 or Windows 10, if you open a standard command prompt, you can access any mapped drive by typing the drive letter plus a colon then hitting enter. However, if you open an administrator command prompt, then when you try to switch to any mapped drive, you get the error: "the system cannot find the drive specified". Anyone know why this is?

The other weird thing is if I drill down using Windows Explorer on the OES source volume to a file that won't copy with robocopy, I can see it. I can then do a Ctrl-C to copy it then I can drill down to the place it is supposed to be on the AD destination volume and paste it just fine! Why is it that Windows File Explorer will allow me to transfer the file but robocopy won't?

Do people have other recommendations for batch copying files?

Thanks,

Dan
Labels (1)
0 Likes
11 Replies
Knowledge Partner
Knowledge Partner

Re: Can't access map rooted drive letter from cmd prompt

dchunt wrote:

> BTW, it looks like, on Windows 7 or Windows 10, if you open a standard
> command prompt, you can access any mapped drive by typing the drive
> letter plus a colon then hitting enter. However, if you open an
> administrator command prompt, then when you try to switch to any
> mapped drive, you get the error: "the system cannot find the drive
> specified". Anyone know why this is?


I encountered that same issue. See this Microsoft article for an
explanation and a solution.

Some Programs Cannot Access Network Locations When UAC Is Enabled
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee844140(v=ws.10)

--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can't access map rooted drive letter from cmd prompt

dchunt wrote:

> We are trying to move files from an OES server to an AD server. In
> the process, we have run into files that appear to have file names
> that are too long to copy, giving us an ERROR 123 in Robocopy. So I
> map rooted a drive letter to a point farther down the path so that
> the file name would be shorter. However, when copying using robocopy
> from the map root, I still get the same errors.


Have you tried to copy the files directly between the two servers?
- Create a shared folder on your AD server.
- Mount that drive on your OES server
- From your OES server, copy the files to the mounted drive.


--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
dchunt Absent Member.
Absent Member.

Re: Can't access map rooted drive letter from cmd prompt

Kevin, I haven't tried that. How would I mount the AD share on the OES server? Using a Samba connection? And then using the Linux cp command to copy from the NSS volume to the AD share?

Dan
0 Likes
dchunt Absent Member.
Absent Member.

Re: Can't access map rooted drive letter from cmd prompt

Kevin, thanks for the reference to the article. That appears to be what is happening. It is just weird that an administrative command prompt has more restrictive rights than a standard cmd prompt.

Thanks,

Dan
0 Likes
dchunt Absent Member.
Absent Member.

Re: Can't access map rooted drive letter from cmd prompt

But wait a minute. If that Windows article was correct, wouldn't I be restricted from accessing anything on a network drive from the elevated command prompt? From the elevated command prompt, I can do a dir and I use UNC nomenclature then I get a directory listing of what is on the drive. But if I type W: {Enter} it tells me that it cannot find the drive. Wouldn't you think either action would return the error?

Dan
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can't access map rooted drive letter from cmd prompt

It's not restricted as such. It's just merely another session. As for local access, you're unrestricted. It just doesn't know about the drive letter which exists in a different context as it's been mapped in the "depreciated" session.
All in all, of course, it's just another brilliant MS idea.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can't access map rooted drive letter from cmd prompt

See the other post. It's not that the elevated session is restricted from accessing the network, it just doesn't know whether and which drive letters are mapped.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can't access map rooted drive letter from cmd prompt

For instance, yes. I'd prefer it vice versa: accessing OES via CIFS from the MS client.
0 Likes
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

Re: Can't access map rooted drive letter from cmd prompt

As is already correctly indicated by others, the drive mappings for
network drives (Client for Open Enterprise Server or any other network
redirector) are stored in a per-Windows-logon-session "DosDevices"
name space which is thereby separate for each logon session. i.e.
Drive "N:" in one logon session is not necessarily mapped at all in
the other session, nor necessarily mapped to the same location, and
vice-versa.

Windows UAC, whether we're talking about Administrator approval mode
or non-Administrator "must enter credentials of an
Administrators-member user" mode is keeping the elevated and
non-elevated processes running under two separate Windows logon
sessions, as is the natural security boundary in Windows.

In a purely Windows environment, you actually _don't_ have access to
the network connections already established in "the other session" of
UAC administrator approval mode. But most often it _looks_ like you
do, because pass-through authentication to resources which require the
same username & password that you logged into Windows with still
occurs in both the elevated and non-elevated sessions.

But if you were prompted for & had to enter credentials to make a
specific Windows SMB/CIFS network connection in the non-elevated
session, you will be prompted _again_ when trying to access that same
UNC from the elevated logon session. They are indeed separate
sessions, and don't already have access to those previous connections.

Now the exceptions:

- The Microsoft "EnableLinkedConnections" overrides the separation of
the DosDevices name space between the elevated and non-elevated
sessions. Client for Open Enterprise Server also honors this policy.
https://support.microsoft.com/en-us/help/3035277/mapped-drives-are-not-available-from-an-elevated-prompt-when-uac-is-co

- The Client for Open Enterprise Server actually allows the
established NCP connections and eDirectory logged-in identities to be
shared across the elevated and non-elevated sessions. This is
intentional as an analog to the "pass-through automatic
authentication" which occurs with the Microsoft redirector, and
presents a similar ease-of-use for NCP in UAC scenarios. This is the
reason for the "but if I enter the UNC, I still could access" behavior
you described, even though the redirected drive letters were still
different.

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com
0 Likes
dchunt Absent Member.
Absent Member.

Re: Can't access map rooted drive letter from cmd prompt

Cool, Alan. That really helps explain what I was seeing. Live and learn, I guess.

Dan
0 Likes
Knowledge Partner
Knowledge Partner

Re: Can't access map rooted drive letter from cmd prompt

mathiasbraun wrote:

>
> For instance, yes. I'd prefer it vice versa: accessing OES via CIFS
> from the MS client.


@Mathias: I suggested this approach because of what Dan said in his OP:

> The other weird thing is if I drill down using Windows Explorer on the
> OES source volume to a file that won't copy with robocopy, I can see
> it. I can then do a Ctrl-C to copy it then I can drill down to the
> place it is supposed to be on the AD destination volume and paste it
> just fine! Why is it that Windows File Explorer will allow me to
> transfer the file but robocopy won't?


Without delving into why this was happening, I thought it might be
easier if we took Windows out of the equation.


@Dan: Mounting a Windows Share to the Linux File System
https://www.suse.com/c/mounting-windows-share-linux-file-system/

--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.