4

Note: I've been able to duplicate my problem by using another WinXp computers instead of a USB drive plugged into my router. Same exact problem. So, the bottom line is that I can access (and modify) the files across the network if I'm doing so manually, but my Windows service fails when trying to do the same thing. If I run the program through Visual Studio, it works. If I run that same exact code as a Windows service, it fails.

I've created a Windows service that needs to access a common network location. To test it at home, I plugged a USB drive into my Netgear N600 WNDR3400 router. The USB storage settings show the workgroup name as Workgroup, and the file path is:

\\readyshare\USB_Storage

The service can't access the files within that network folder. I get an error that the file can't be found, or that permission was denied, depending on what I try. (The file does indeed exist.) However, I can access/modify those files directly from my laptop (Win8), and I can do the same thing on my wife's laptop (WinXP). The service is running as the Local System user.

I've tried running as Network Service, as .\administrator, and as .\JaneDoe. No luck.

I also tried changing the permissions on the newtwork folders, but it doesn't stick. For example, if I try to give Everyone full control:

enter image description here

It just reverts to the previous state after I hit apply:

enter image description here

I've also tried adding a new user (see Add button above), but then I get this error:

enter image description here

Any ideas how I can make this work? I simply want my service to have read/write (even full, I don't care) access to the folders on this network.

Edit - I used Process Monitor, and, as expected, this is the error:

enter image description here

More Failed Attempts

  • Use different USB drive
  • Disable Windows firewall on the XP box
  • Instead of using the UNC path, use a mapped drive

EDIT - Code to Access the Network Files Note: The file is not found (even though it exists).

private UpdaterManifest GetUpdaterManifest()
{
    string filePathAndName = Path.Combine(this._sourceBinaryPath, this._appName + ".UpdaterManifest");

    if (!File.Exists(filePathAndName))
    {
        // Always hit here
    }
}
6
  • Can you post the code that's used to access the file?
    – Supun
    Feb 18, 2013 at 19:55
  • Also try the following links : link or link
    – Supun
    Feb 18, 2013 at 20:05
  • @Supun I've tried many things, including items in the links you provided. Nothing has worked so far. I also posted my code at the end of my question.
    – Bob Horn
    Feb 20, 2013 at 2:29
  • Home. It's in the new title. :)
    – Bob Horn
    Feb 20, 2013 at 2:48
  • Pretty ambiguous. It could be a "Windows XP" ... wait for it ... "Home Network" or "Windows XP Home" "Network" ... you see? Also this means I don't know the answer (or am unsure at least). I would have known it for Pro. Feb 20, 2013 at 2:50

1 Answer 1

1

So you want to access a share on an XP Home machine over the network, where the client is running as a service on either Windows XP Home or Windows 8?!

There are a number of aspects playing into this and you need to get all of them right. Assuming your service runs as SYSTEM (aka LocalSystem) you'll have to ensure the following:

  1. the share itself needs to have the correct permissions (Everyone needs the appropriate ACLs set) - this is a problem point on Windows XP Home as it lacks the security editor (on the other hand that means that under normal circumstances you won't even be able to mess with the permissions in the first place and the defaults may work) ... there seems to be an XP Home specific tool to assign share permissions. You can execute it as shrpubw (Presumably for "share ... wizard"?). See this link.
  2. the folder that you share out also needs the appropriate permissions for Everyone. - you can do that with cacls on the command line
  3. the most important in my experience is to set the computer policy properly. Unfortunately this is exactly where you get stuck in XP Home, because MS intentionally crippled the features of that Windows edition.
    • One policy setting affecting this would be "Network access: Shares that can be accessed anonymously" - which, I think you can set manually in the registry by manipulating HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters value NullSessionShares (REG_MULTI_SZ) ... it's a value made up of multiple values. In regedit it will appear as multiple lines. One one line add the name of the share. I.e. if your share is \\readyshare\USB_Storage from the client, the share name is USB_Storage. After that run net stop lanmanserver followed by net start lanmanserver (this service is called Server under Computer Management/MMC) ...
    • Another policy affecting it is "Network Access: Let Everyone permission apply to anonymous users" - this one I am not 100% sure about, but I think it correlates to the setting at HKLM\SYSTEM\CurrentControlSet\Control\LSA value RestrictAnonymous (REG_DWORD, see this KB article) which needs to have the value 0 (but defaults to 1). I am not sure you can dodge the reboot with this setting.

And one more thing, it's well possible another ingredient is missing. But that works for a software that I ran at some point which requires this to be set for their update mechanism in the LAN to work.


Thanks to the chat facilities we figured it out interactively. Using shrpubw (mentioned in an edit to the first point above) did the trick as follows.

From the start menu choose "Run"

... enter shrpubw and press ENTER.

Run dialog

Proceed immediately to the next step in the wizard

... skipping this:

Step 1 shrpubw

Point to the proper folder to share and name the share

Like this:

Step 2

... and continue with "Next"

Select "Custom" for the permissions in the next step

Here:

Step 3

... after clicking the "Custom" button you'll be presented this:

Security Editor

... now make sure to adjust the permissions as needed. The "Everyone" entity is usually what you want to adjust. On XP Home it should imply "ANONYMOUS LOGON", which is affected by the settings pointed out in the first part of this answer (point 3).

Save the permissions and go to the next step.

Finish the wizard

... like this:

Last step

... or start over to add another share by checking the checkbox before clicking the button.

NOTE: very likely the policy settings mentioned above affect this as well (point 3). So this step is likely still necessary on the "server" (that is the machine that provides the share).

1
  • +1 for the good tips and the help via chat. Working through it now. I wish I could give you more points than one upvote (and possibly the accepted answer). Thank you.
    – Bob Horn
    Feb 20, 2013 at 3:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .