Security – NETWORK SERVICE is unable to save to a network path

The "Share Permissions" can be "Everyone / Full Control"-- only the NTFS permissions really matter. (Cue religious arguments from people who have an unhealthy attachment to "Share Permissions" here...)

In the NTFS permissions on the folder on ServerB you could get by with either "DOMAIN\ServerA - Modify" or "DOMAIN\ServerA - Write", depending on whether it needed to be able to modify existing files or not. (Modify is really the preferred because your application may re-open a file after it creates it to write further-- Modify gives it that right, but Write does not.)

Only the "SYSTEM" and "Network Service" contexts on ServerA will have access, assuming you name "DOMAIN\ServerA" in the permission. Local user accounts on the ServerA computer are different from the "DOMAIN\ServerA" context (and would have to be named individually if you somehow did want to grant them access).

As an aside: Server computer roles change. You may want to create a group in the AD for this role, put ServerA into that group, and grant the group rights. If you ever change ServerA's role and replace it with, say, ServerC, you need only change the group memberships and you never need to touch the folder permission again. A lot of admins think about this kind of thing for users being named in permissions, but they forget that "computers are people too" and their roles sometimes change. Minimizing your work in the future (and your ability to make mistakes) is what being efficient in this game is all about...

I was trying to find what I remember to be a MS blog post about the "network service" account however I was unable to locate it in a quick search through my bookmarks. At any rate what I recall from it is that indeed this account is considered a special user account that while having additional security authorizations not normally assigned to a basic user account it also is strapped with other limitations. If I recall the accounts ability connect to network resources is one of those limitations.

That being said though I can also tell you that I have been in a similar sounding situation and there are ways to make things work. I can tell you that in instances where I have web services that need to access network resources as a part of it's functions as the app pool identity we specify a domain based account which would be a member of your HURFDURFGROUP group for it's share access. Then to make it a functional service account for the IIS app pools you make sure it's a member of the local IIS_WPG group as well as running "aspnet_regiis" with the -ga domain\username from the version of asp.net framework you are using. This essentially will grant that account all of the permissions necessary for it to function as the apppool identity for that local system.

Not exactly a direct answer to your question, but perhaps will be helpful anyway.