When PsExec fails to access a shared folder, the issue usually stems from network discovery being disabled, incorrect UNC path syntax, or insufficient administrative privileges on the target machine. Verify that both source and destination computers are on the same workgroup or domain, ensure the C$ or specific share is visible in File Explorer, and confirm that the account running PsExec has local administrator rights on the remote host to bypass UAC restrictions.
Verifying Network Discovery and Connectivity
The most common reason for PsExec not seeing a shared folder is that the underlying network stack does not allow the necessary traffic or visibility. PsExec relies on the SMB (Server Message Block) protocol to communicate with remote systems. If network discovery is turned off, the remote computer will not appear in the network neighborhood, and direct UNC paths may fail due to strict firewall rules. First, check the network profile of both the local and remote machines. They should be set to either "Private" or "Domain." If they are set to "Public," Windows Firewall will block incoming connections by default. You can verify this by opening the Network and Sharing Center and checking the current network type. Next, ensure that file and printer sharing is enabled. Even if you know the IP address, many modern Windows configurations require explicit permission for SMB traffic. Run the following command in an elevated Command Prompt on the remote machine to ensure the firewall allows inbound SMB connections:netsh advfirewall firewall add rule name="Allow SMB Inbound" dir=in action=allow protocol=TCP localport=445nslookup to verify that the hostname resolves correctly to the expected IP address. If DNS is unreliable, try using the IP address directly in your PsExec command to isolate whether the issue is name resolution or actual connectivity. For more details on resolving such network issues, see our guide on DNS and NSLOOKUP: Troubleshooting Network Connectivity Issues.
Correcting UNC Path Syntax
PsExec requires a specific format for specifying remote computers. Many users attempt to use a simple hostname or an IP address without the proper administrative share context. When accessing shared folders, you must use the Universal Naming Convention (UNC) path. The correct syntax for targeting a specific share is:psexec \\ComputerName\ShareName commandC$, D$, or ADMIN$) by default. If you are trying to execute a script located in a custom shared folder, you must ensure that the share permissions allow the connecting user to read and execute files. Standard network shares often lack the necessary execution rights for remote services.
It is also important to note that PsExec cannot directly browse the network to find shares. You must provide the exact path. If you are unsure if the share is accessible, test it manually by typing \\ComputerName\ShareName into the Windows File Explorer address bar. If it opens, the network layer is functional, and the issue lies elsewhere. If it fails, check the share permissions on the remote server's properties dialog under the "Sharing" tab.
Handling Administrative Privileges and UAC
Even with correct paths and network settings, PsExec often fails due to User Account Control (UAC) restrictions. By default, PsExec attempts to create a service on the remote machine and run the command under that service's context. This process requires high-level administrative privileges. If the account you are using is a member of the Administrators group but still fails, it is likely because of Remote UAC filtering. In Windows Vista and later versions, even administrators have two tokens: a standard user token and an elevated administrator token. PsExec uses the standard token by default unless explicitly told otherwise. To bypass this, you can use the-accepteula flag along with the -u and -p flags to specify credentials if you are not already logged in as an admin. More importantly, you may need to disable remote UAC filtering on the target machine. This can be done by modifying the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy and setting its value to 1. This change grants full administrative privileges to local accounts over the network without requiring additional authentication prompts.
For users encountering specific access errors on newer Windows 11 builds, refer to our troubleshooting article on Fixing PsExec Access Error on Windows 11 23H2 and 24H2, which addresses recent security changes affecting remote execution.
Testing with Alternative Tools
If PsExec continues to fail despite verifying all the above steps, consider whether the environment supports legacy service creation. Some hardened environments disable the ability to create new services via RPC. In such cases, PsExec is fundamentally incompatible with the security policy in place. An alternative is to use PowerShell Remoting (WinRM). Unlike PsExec, which relies on SMB and service creation, WinRM uses HTTP/HTTPS ports (5985/5986) and is designed for modern automation. Ensure that WinRM is configured on the target machine by runningEnable-PSRemoting -Force locally. Then, use Invoke-Command to execute scripts remotely. This method is generally more secure and less prone to the "shared folder not seen" errors associated with SMB-based tools.
Another option is to copy the necessary files to the remote machine using Copy-Item with the -ToSession parameter if you have an active PowerShell session, or use robocopy via PsExec with the -s flag to suppress output while copying, ensuring the file exists locally before attempting execution.
Frequently Asked Questions
Why does PsExec say "Access Denied" even with admin rights?
This error typically occurs because of Remote UAC filtering, which downgrades your administrative token when connecting over the network. To fix this, enable theLocalAccountTokenFilterPolicy registry key on the target machine or use the -u and -p switches to explicitly provide elevated credentials during the PsExec call.
Can I use PsExec to access a non-administrative network share?
Yes, but you must specify the exact UNC path including the share name (e.g.,\\Server\Share). However, PsExec runs commands under a service context, which may not have the same network credentials as your interactive login. You may need to map the drive within the command string or ensure the service account has permissions to that share.
What is the difference between PsExec and Invoke-Command?
PsExec uses SMB and creates a temporary service on the remote host, which can trigger antivirus alerts and require administrative shares.Invoke-Command uses PowerShell Remoting (WinRM) over HTTP/HTTPS, is more secure, supports better data serialization, and does not rely on creating local services, making it preferred for modern automation tasks.