Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Since you use the word "workgroup", does that mean these servers are not members or controllers of a domain? –  charnley Jun 20 '11 at 15:31
    
I'm not entirely sure (I'm not the one who administrates the network). If I look at the current security principals in some random folders on C in each server, it has the form of SERVERNAME\USERNAME - I don't know if that's just the way it always is, or if it means both servers are in their own domains, where the domains are named after the servers. –  Tomas Lycken Jun 20 '11 at 16:15
    
So you don't have admin-level access? If not, sharing files between the server will have to be set up by the network admin. –  charnley Jun 20 '11 at 16:23
    
@charnley: I do have admin-level access - I'm just not the individual responsible for the network setup, so I don't know exactly how it works. I have admin access to be able to do this sort of thing every now and then, but the main network administration is carried out by someone else. –  Tomas Lycken Jun 21 '11 at 6:30
    
Can you post a picture of the security settings on the two folders ? –  Ninja Jun 22 '11 at 12:34

4 Answers 4

  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.

share|improve this answer
5  
Note that Share permissions are a legacy system (for Win9x systems). They're still present, but generally speaking should always be set to Full Control and you should use NTFS permissions to restrict and control access. Share permissions apply to the whole share, making them very ham-handed. Additionally, they are more difficult to manage as you can easily have permission conflicts. Many people have a hard time believing they should do this, however. Essentially, you need to think of Full Control on Share permissions as turning Share permissions off completely. –  Bacon Bits Jun 22 '11 at 19:00
1  
+20 for Bacon Bits, if I could. –  Evan Anderson Jun 22 '11 at 20:01
3  
I can't believe some of the absurdities I'm seeing here. Share permissions are most certainly not a "legacy" system, they are the first level of security. They should be be used correctly, not just set at Full Control for everyone. NTFS permissions are the second layer, which provides greater control at the file and folder level but nobody should reach that level unless they have been specifically granted access via the share permissions. Ignorance of how to propely use share permissions is a massive security hole. –  John Gardeniers Jun 28 '11 at 10:32
3  
@Scott Forsyth / @John Gardeniers: I believe Share Permissions are a legacy feature used for giving NTFS-like permission behavior to shared folders on filesystems like FAT (and, back in the day, HPFS). I'd argue that "repeating yourself" by specifying redundant Share Permissions adds unnecessary complexity and provides no real security. re: Scott and "What if ... Users with read permissions": Your NTFS permissions should be right, period. NTFS provides a single unambiguous method for controlling who can access filesystem resources and what access they have. Since Share Permissions ... –  Evan Anderson Jun 28 '11 at 15:03
3  
@Scott Forsyth and @John Gardiners: I don't have the energy to argue about this. I've been using Windows NT since version 3.51. I understand it just fine. I've always used this "feature" this way and I'll continue recommending to other to use it in this way. NTFS permissions should be carefully planned and administered because the permission "buck" stops with them. "Share Permissions" are an ineffective "firewall" in my opinion, add complexity needlessly, and are an artifact of a bygone era. This medium doesn't lend itself to nuanced debate so we'll just have to agree to disagree. –  Evan Anderson Jun 28 '11 at 21:55

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.

share|improve this answer
    
Isn't this what I said? Albeit in a roundabout way ... –  Daniel Ball Jun 23 '11 at 11:21
    
@Daniel, you described a symptom. I described the reason for that symptom. –  John Gardeniers Jun 26 '11 at 9:27
    
Thanks for your answer! Please see my update with more information on accounts and setup. –  Tomas Lycken Jun 27 '11 at 8:34

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>
share|improve this answer
    
Thanks for your answer! I am in a workgroup environment, and regarding the user account I'm required to use the SYSTEM account on A. Please see my update. –  Tomas Lycken Jun 27 '11 at 8:37
    
Since it's TeamCity, can you use a task that allows you to specify the credentials? The task that you're working with may support that. Another option is to use FTP which also allows you to specify the credentials . If those don't work, I would recommend changing the task that TeamCity runs under from System. As long as the account is an administrator on the A server it should continue to work. Then you are controlling the account to use on the network. Otherwise Pass-through authentication won't work since Server A will see A$ (anonymous computer account) rather than a particular user. –  Scott Forsyth - MVP Jun 27 '11 at 16:00
    
@Scott: Thanks! I've updated my config so that the build agent runs under a specific account (which works thanks to your note on adding it to the admins group), but I still can't get the copy task to work. Please take a look at my updated question. –  Tomas Lycken Jun 28 '11 at 8:45
    
Looks like good progress, and good troubleshooting steps. My assumption at this point is that the string format isn't what TeamCity expects. Maybe it requires a trailing slash, or something of that nature. I'll edit my reply with a TeamCity example that works for me. –  Scott Forsyth - MVP Jun 28 '11 at 13:36
    
I inserted this in my build script, and got an error saying "C:\TeamCity\buildAgent\work\905a6382449fdab\NCVIB.SMSServices.targets(96, 7): error MSB4067: The element <fileset> beneath element <copy> is unrecognized.". Was this supposed to be a MSBuild snippet? If not, where (since not in my .build file) should I put it? –  Tomas Lycken Jun 29 '11 at 7:06

You should be able to do this by creating the same local user on each system. Exact same username, exact same password. Then run your service using those credentials. Also set the NTFS ACLs as you were and give the local account on each system access, as well as in the share permissions.

share|improve this answer
    
Thanks for your answer! However, I am required to make this work with the SYSTEM account on one of the servers. See my update for details. –  Tomas Lycken Jun 27 '11 at 8:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.