Security permissions for remote shared folders

I have two servers running Windows Server 2003, and I want copy files from one server (A), programmatically with a windows service running under the Local System account, to a shared folder on the other (B). I keep getting "access denied" errors, and I can't figure out what security settings I need to set to open the shared folder for writing.

This is what I've done on the recieving end:

1. On A, right-click on the folder to share, choose the tab "Sharing" and select "Share this folder". Set a share name.
2. Click "Permissions", add the group "Everyone" and give it full control.

I tried choosing the "Security" tab to give some permissions there as well, but the "Add" dialog only finds local users, despite the fact that B shows up in the "Workgroup computers" dialog. After further inspection, this is the case also for the "Permissions" dialog under the "Sharing" tab (are they the same?).

Update: I have done some further research, and found that the program on server A is run under the SYSTEM account. This is not something I dare change, because of the risk to break other things that this program also does (it's a build agent on our TeamCity CI server).

Thus, I need a way to give A\SYSTEM access to write in a shared folder on B, in a workgroup environment.

Update 2: I've now been able to do the following changes to my configuration:

• There is a user account on each server named TeamCity. They have the same passwords, and are both parts of their respective Administrators group (which I've verified by logging on via remote desktop to both servers using the same information).
• TeamCity (specifically \\B\TeamCity) has full control access to the shared folder on B.
• The build agent on A runs under the \\A\TeamCity account.

When I try to copy files this time, I get an error stating

Could not find part of the path '\\B\Shared.Folder.Name'

I can copy the path from the error message and paste it into the address bar in Windows Explorer when logged on to the TeamCity account via Remote Desktop, and explorer navigates to the shared folder on B.

Solution 1:

1. In a workgroup there is no central repository of users, so you have to manually duplicate the accounts on each workstation (or server in your case)
2. In a workgroup, LocalSystem accesses the network as Anonymous.

You should have the service run as a different account. Create an account with the same name/password on both machines, grant share permissions to the Service account and set the service to run as that rather than LocalSystem: start > run : services.msc right click the service and go to properties. Change the logon to the user account you created.

If that doesn't work, you can configure the receiving folder to accept writes from Anonymous, but not read/execute. that would make the folder work like a drop box.

To answer your question about "security" and "share" permissions, no they are not the same. Security is NTFS permissions ... that's permission to access the file system. Share permissions is permission to access that resource across the network. The most restrictive of the two wins, so if you set Everyone to Full Control in security settings but Everyone to Read Only in share, you will get Full Control if you access the resource locally, but only read access if you try to use it from another computer.

Solution 2:

The Local System account has no permission to access network resources. You will need to either have it run a process which can make the connection using suitable credentials or run the service under another account, which will still need to use suitable credentials to access the remote resource.

Solution 3:

You are likely on a domain. I would recommend using domain accounts if you are. Pass-through authentication is possible, as mentioned already, but it's meant for a workgroup only, or if you're really restricted in what your domain admin will give you (although that suggests that you're doing something that your network admin won't support).

Here's how you can check if you're on a domain.

• Click Start. Right-click My Computer and click Properties
• Click the Computer Name tab
• You can kind of tell from this screen, but click Change
• See if Member of is Domain or Workgroup.

If it's Workgroup, then use the pass-through authentication mentioned already. (exact same username/password on both machines)

However, if it's in a domain, what I recommend is that you ask your domain admin for a service account that you can use here. Don't use your own account since password changes and such will cause your service to break.

In the Add dialog box, there is a Locations... button. Click on that and make sure that your domain is selected (if you're going down the domain path). That will give you access to domain users.

In either case (Workgroup or Domain), update your service account on A that you're using so that it uses that account, rather than using Local System.

Grant the new account only what permissions it needs to the Share and to the Security tab (NTFS permissions). I wouldn't grant Everyone access to either the Share or NTFS, since that opens up your computer to anyone on the domain.

Note: sometimes it's fine to test using the Everyone group to remove permissions as an issue during testing, but be sure to tighten the final configuration. That should be temporary only.

Update: Based on discussion in the comments, here's an example of a TeamCity config that's based on a working config of mine.

<property name="source.root" value="D:\svn\trunk\admin"/>
<property name="staging.directory" value="\\B\Shared.Folder.Name"/>
<property name="directory.to.upload" value="${source.root}\ControlPanel"/>

<target name="network.deploy">
<echo message="-------- NETWORK.DEPLOY ---------------"/>
    <copy todir="${staging.directory}" verbose="true">
        <fileset basedir="${directory.to.upload}">
            <include name="**/*"/>
            <exclude name="**/*.vb"/>
        </fileset>
    </copy>
</target>