When dealing with services running under the NT AUTHORITY\SYSTEM account (commonly referred to as the SYSTEM account), administrators often encounter permission issues when accessing network resources. The error message "the account name could not be found" typically occurs because the local SYSTEM account exists only in the security context of the local machine.

The SYSTEM account doesn't traverse network boundaries in the way domain accounts do. When your service running as SYSTEM attempts to access a network share, it's actually using the computer account (DOMAIN\SERVER-NAME$) for network authentication.

Here are three effective approaches to resolve this:

1. Granting Access to Computer Account

The most straightforward method is to grant permissions to the server's computer account:

# PowerShell: Grant share permissions
Grant-SmbShareAccess -Name "SharedFolder" -AccountName "DOMAIN\SERVER-NAME$" -AccessRight Full -Force

2. Using Group Policy Preferences

For domain-wide deployments, create a Group Policy Object (GPO) with these settings:

# XML for Group Policy Preferences
<DriveMap clsid="{935D1B74-EB81-44CE-9F1B-79B1B86F8BCB}">
  <Properties action="U" thisDrive="NOCHANGE" allDrives="NO" userName="" 
  path="\\fileserver\shared" label="SharedFolder" persistent="1" useLetter="1" 
  letter="S" />
</DriveMap>

3. Service Account Alternatives

For critical services, consider using a managed service account:

# Create and configure a gMSA
New-ADServiceAccount -Name "svc_FileAccess" -DNSHostName "fileserver.domain.com"
Add-ADComputerServiceAccount -Identity "SERVER-NAME" -ServiceAccount "svc_FileAccess"

After implementing any of these solutions, verify the access:

# Test from the source server
Test-Path "\\fileserver\shared\testfile.txt" -ErrorAction Stop

• Always follow the principle of least privilege
• Audit access regularly with Get-SmbShareAccess
• Consider creating dedicated shares for SYSTEM services

---

The Windows SYSTEM account (NT AUTHORITY\SYSTEM) is a special local account with elevated privileges, often used by services and system processes. When dealing with network resources in a domain environment, you might encounter situations where a service running as SYSTEM needs to access a shared folder on another server.

Attempting to add "SERVER-NAME\SYSTEM" directly in share permissions fails because:

• The SYSTEM account is local to each machine and doesn't exist in the domain's security principal database
• Share permissions dialog validates accounts against the domain controller

Here are three effective approaches to solve this problem:

1. Using Computer Account Instead

The computer's domain account (DOMAIN\SERVER-NAME$) can represent the SYSTEM context:

# PowerShell command to grant access
Grant-SmbShareAccess -Name "ShareName" -AccountName "DOMAIN\SERVER-NAME$" -AccessRight Full -Force

2. Group Policy Preference

Configure share permissions via Group Policy:

1. Create a GPO and navigate to: Preferences > Windows Settings > Files
2. Add a new shared folder
3. Set security to include "DOMAIN\SERVER-NAME$"

3. Scheduled Task Workaround

Create a scheduled task running as SYSTEM that maps the drive:

# Command to create scheduled task
schtasks /create /tn "MapNetworkDrive" /tr "net use Z: \\server\share /persistent:yes" /sc onstart /ru SYSTEM

For service accounts requiring persistent access, consider these alternatives:

Service Principal Name (SPN) Configuration

# SetSPN command example
setspn -S HOST/SERVER-NAME.domain.com DOMAIN\SERVER-NAME$

Delegation Settings

Configure constrained delegation in Active Directory for the computer account.

• Always verify effective permissions using "Effective Access" tab in Security properties
• Check security logs (Event ID 5145 for file share access attempts)
• Test with ProcMon to verify the exact account attempting access