CODEWITHSUNDEEP
c#winapi
eyal
eyal

Reputation: 379

NetUseAdd returns error 67 or 87

I'm calling the NetApi32.dll method NetUseAdd.
This is how: 

USE_INFO_2 useinfo = new USE_INFO_2();

useinfo.ui2_remote = UNCPath;
useinfo.ui2_username = User;
useinfo.ui2_domainname = Domain;
useinfo.ui2_password = Password;
useinfo.ui2_asg_type = 0;
useinfo.ui2_usecount = 1;
uint paramErrorIndex;
returncode = NetUseAdd(null, 2, ref useinfo, out paramErrorIndex);

When calling this with useinfo.ui2_remote = \\servername\dirname it returns code 67 and when calling with useinfo.ui2_remote = \\servername\dirname\ it returns code 87.

When I say it returns code...I mean that either it throws exception and Marshal.GetLastWin32Error() returns this error code, or the actual call to NetUseAdd returns it.

The weird thing is, that this method succeed when calling this with a path that doesn't have dub-folders, and fails when calling with a path that has sub-folders.

The calling machine is Windows server 2008, and the remote is a linux server (I'm not sure what version or distribution).

Any idea how can I successfully connect\use the remote resource without worry about the subfolder issue?

edit: 

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
internal struct USE_INFO_2
{
     internal LPWSTR ui2_local;
     internal LPWSTR ui2_remote;
     internal LPWSTR ui2_password;
     internal DWORD ui2_status;
     internal DWORD ui2_asg_type;
     internal DWORD ui2_refcount;
     internal DWORD ui2_usecount;
     internal LPWSTR ui2_username;
     internal LPWSTR ui2_domainname;
}

[DllImport("NetApi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
internal static extern NET_API_STATUS NetUseAdd(
     LPWSTR UncServerName,
     DWORD Level,
     ref USE_INFO_2 Buf,
     out DWORD ParmError);

More info worth mentioned: the remote path that I'm trying to Add using NetUseAdd is a Huge storage (7 TB). A simple access with Windows explorer takes about 3-4 seconds to reach, but eventually it appears.

Upvotes: 3

Views: 15012

Answers (5)

Uwe Keim
Uwe Keim

Reputation: 40736

In my case, I had an outdated P/Invoke signature as described here.

Old, wrong:

[StructLayout(LayoutKind.Sequential)]
public class NetResource
...

New, correct:

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public class NetResource
...

Upvotes: 1

Beanwah
Beanwah

Reputation: 1290

I found that the folder path is case sensitive as there should be no trailing backslashes in the path, as mentioned before.

After I changed that it worked.

Upvotes: 1

Dale
Dale

Reputation: 1731

I was having a similar issue connecting to a Linux server. The solution that worked for me was to map a network drive from Windows manually using the login credentials first, this must create some internal configuration that then allowed connection using NetUseAdd. I only had to map the drive once.

Upvotes: 0

Ashavsky
Ashavsky

Reputation: 51

I was having this same issue and managed to find out the culprit - if using the source code from Original Article I noticed that it would only allow me to connect when not running visual studio as administrator (my default set up). Hope this helps someone else frustrated by this!

Upvotes: 1

hmadrigal
hmadrigal

Reputation: 1050

I am not am expert on this topic but I was using something like:

@"\\10.22.15.14\C$\Inetpub\wwwroot\db\archive\"

and I got a error code 87, then I changed the string to be

@"\\10.22.15.14\C$\Inetpub\wwwroot\db\archive"

and it worked. perhaps, it may work for somebody else.

Upvotes: 8

Related Questions