User/password problems with GetVolumeNameForVolumeMountPoint() (Windows remote drive mount?)
Asked Answered
P

2

2

From a Vista workstation, I have an attached XP Embedded computer on which I want to programmatically mount a volume locally (e.g., mount the XP Embedded \\MyXPEmbedded\C:\some\path\ to the Vista workstation (mounted to C:\mounted_XPEmbedded\).

(This is an administrative utility that runs on the Vista workstation that maintains files on the XP Embedded workstation, which is part of a larger device.)

I can see the XP Embedded computer from the Vista workstation. For example, I can ::getnameinfo() to resolve the XP Embedded computer's name from its IP address.

However, all calls to GetVolumeNameForVolumeMountPoint() fail (returns false), with the formatted message from ::GetLastError() being:

Logon failure: unknown user name or bad password

So clearly, this seems to be a permissions problem. However, I see no discussion in the Microsoft APIs how I may provide the user/password through these volume GUID path APIs.

When "browsing" the XP Embedded from the Windows Explorer on the Vista workstation by typing the IP address for the XP Embedded machine into the address bar, I get prompted for a user name and password, after which I can see everything on the XP Embedded (duh! How do I provide that programatically?)

QUESTION: How can I provide the user login/password programatically when working with the GUID path APIs (and specifically ::GetVolumeNameForVolumeMountPoint() )?

Part of the problem may be that these computers do not share the same domain (they can't, the Vista computer will be added to the customer's domain, the XP Embedded must be "hidden").

Other info, which probably is not important:

  • The Vista workstation and XP Embedded do not share the same domain (they can't)
  • Application runs on Vista workstation under an account with Administrative permissions (I assume this is required?)
  • That Vista administrative account is not present on the XP Embedded computer (the XP Embedded has a different administrative account)
  • The clocks between both computers are current (security credentials should work)
  • The Vista workstation has two network cards, one card connects directly to the XP Embedded box, which has only one network card
  • Using C++, MSVS2008

BONUS QUESTION: It would be nice if I could run this administrative utility on the Vista workstation without administrative permissions, is this possible? (I know the administrative login/password for the XP embedded.)

Peachy answered 22/6, 2011 at 22:28 Comment(0)
G
2

Make a call to WNetAddConnection2 before trying to access the shares on the embedded box. You might need to have username in the form of MyXPEmbedded\[admin username].

You may come across issues if you have already tried to make connections to the embedded box previously. To remove any of the lingering connections you can use, from the command line - net use with the /delete option. You can also play with establishing the connection w/ net use before running your program for debugging purposes.

As far as running w/o admin privileges that will mostly have to do with where you decide to make the local mount point, but you could probably get away with just using the UNC path. Using the default administrative shares (which are enabled if "use simple file sharing" is disabled) you can access the embedded system using something like \\MyXPEmbedded\c$\some\path.

Gambill answered 30/6, 2011 at 18:17 Comment(1)
Very helpful, so +100. I can mount remotely with WNetAddConnection2(), but ::GetVolumeNameForVolumeMountPoint() still has logon failure (same user name/password message). But, at least I can get a local drive letter for the moment (I'll need to fix this, because many of our machines auto-mount all 26 drive letters, and none are available). So, I'm still open to suggestions. ;-)Peachy
L
2

You probably need to establish at least one SMB (named pipe / file share) connection from the Vista workstation to the XP workstation, on any share with sufficient rights, like \\myXP\whatever or \\myXp\c$ or even \\myXP\icp$, prior to be able to open any network path targeting "myXP" computer.

You can do that programmatically using the WNetAddConnection2 Function, with a user name and password.

Lamm answered 25/6, 2011 at 14:31 Comment(1)
Success mounting remote to local drive letter with WNetAddConnection2() with user/password, and even securing remote drive without redirecting to local drive letter. Still fail with ::GetVolumeNameForVolumeMountPoint(). I voted you up (good answer), but gave the bounty to dallbert for the extra hints (I'm still working on the login failure with the same error message). Thanks for your help!Peachy
G
2

Make a call to WNetAddConnection2 before trying to access the shares on the embedded box. You might need to have username in the form of MyXPEmbedded\[admin username].

You may come across issues if you have already tried to make connections to the embedded box previously. To remove any of the lingering connections you can use, from the command line - net use with the /delete option. You can also play with establishing the connection w/ net use before running your program for debugging purposes.

As far as running w/o admin privileges that will mostly have to do with where you decide to make the local mount point, but you could probably get away with just using the UNC path. Using the default administrative shares (which are enabled if "use simple file sharing" is disabled) you can access the embedded system using something like \\MyXPEmbedded\c$\some\path.

Gambill answered 30/6, 2011 at 18:17 Comment(1)
Very helpful, so +100. I can mount remotely with WNetAddConnection2(), but ::GetVolumeNameForVolumeMountPoint() still has logon failure (same user name/password message). But, at least I can get a local drive letter for the moment (I'll need to fix this, because many of our machines auto-mount all 26 drive letters, and none are available). So, I'm still open to suggestions. ;-)Peachy

© 2022 - 2024 — McMap. All rights reserved.