I want to monitor a disk share with PRTG, but the sensor is in error-state, even though I can access the share with my Windows Explorer. What can be done to troubleshoot the issue?
What can I do if PRTG doesn't succeed with monitoring a share? PE029 PE032
This article applies to PRTG Network Monitor 12 or later, as well as to previous (deprecated) versions
Troubleshooting Share Monitoring with PRTG
A network share is generally a computer object that can be accessed from another computer over a LAN, allowing said object to be virtually used as an object belonging to the local machine. Although PRTG Network Monitor is able to monitor said shares using the File, Folder and SMB Share sensors, we have received multiple user reports stating that this type of access is not working properly in some instances.
Although we cannot precisely explain why users are getting errors when adding shares (in most instances the error stems from the Windows API) and, although at times it is possible to connect to said shares using Windows Explorer, this does not automatically mean it will work with PRTG as well. However, there are a few things one can try in such situations:
- Double check the 'share' setting in the sensor, so that it starts with the share name and not with any backslashes or the target machine name
- Try the computer/netbios name, the fully qualified domain name and the IP address as 'Host' setting in the corresponding (target) device
- Check that the IPC$ share is available at the target host
- Check that the firewall is open (UDP and TCP) for ports 137-139 and especially for port 445 for all applications/users
- Check that no other software (Internet security/virus scanner) intercepts the connection. Try temporarily disabling these applications
- Use a domain admin account as service logon name for the probe device
- Check the group policies whether Windows service applications have restrictions for remote logons or share connections or similar
- Try the 'non-service' version of the PRTG probe If all of the above fails, please search for the exact error message (without the error number in parenthesis): you should get a large number of results which might help finding the actual cause for this issue.
There are no settings in PRTG except the host name (device), the share name (sensor) and the Windows credentials (device or inherited from above groups) which actually affect sensors using SMB Shares.
PE Error Codes
Some errors you might encounter—and the solution:
Login failure: The network location cannot be reached. For information about network troubleshooting, see Windows Help (1231). (code: PE029)
Please make sure the "Server" Windows service is running on the target computer and that you are allowed to access the share with the credentials provided.
Cannot access folder: The folder doesn't exist (code: PE032)
Please make sure you entered the right network path in the sensor settings. When monitoring a share, please create a PRTG device with the computer name or IP address in the IP Address/DNS Name field, and in the sensor's Folder Name settings, enter the path only. For example, enter MyComputer in the device, and C$\Inetpub\mailroot in the sensor's Folder Name field in order to monitor the network path \\MyComputer\C$\Inetpub\mailroot
Logon failure: A specified logon session does not exist. It may already have been terminated(1312) (code: PE029)
The drive you are trying to map needs a specified logon session even the username and password are correct. In the "Credentials for Windows Systems" settings of the PRTG device, please explicitly enter a value in the "Domain or Computer Name" field. This can be the computer name (if you're using a local login) or the domain name of the user account. Note: After changing credentials, it may take several minutes until the connection is successful.
I have the Problem:;
'Logon failure: A specified logon session does not exist. It may already have been terminated(1312) (code: PE029)'
I just check the login password. I Have this problem since I update the PRTG Version from 14.4.12 to 14.4.13
This is a remote probe, so it's quite impossible that it's a domani/ip address lem
This looks like it is an issue with a scheduled task. Are you monitoring any of these with PRTG?