FileSystemWatcher Fails to access network drive

Solution 1:

I have projects using the FileSystemWatcher object monitoring UNC paths without any issues.

My guess from looking at your code example may be that you are pointing the watcher at the root share of the server (//servername/) which may not be a valid file system share? I know it returns things like printers, scheduled tasks, etc. in windows explorer.

Try pointing the watcher to a share beneath the root - something like //servername/c$/ would be a good test example if you have remote administrative rights on the server.

Solution 2:

With regards to the updated question, I agree that you probably need to specify a valid share, rather than just the remote server name.

[Update] Fixed previous question about the exception with this:

specify the name as @"\\someServerPath"

The \ is being escaped as a single \

When you prefix the string with an @ symbol, it doesn't process the escape sequences.

Solution 3:

I was just asked this question in regards to FileSystemWatcher code running as a service and the issue is permissions. I searched and found this question and answer but unfortunately none of the answers here solved the problem. Anyway, I just solved it, so I thought I would throw in the solution here for next guy who searches and find this question.

The drive was mapped as a logged in user but the service was running as LocalSystem. LocalSystem is a different account and does not have access to drives mapped by a user.

The fix is to either:

1. Authenticate first (I use a C# Class to establish a network connection with credentials)
2. Run your service as a user that has access to the share.

You can test LocalSystem authentication by using a LocalSystem command prompt, see How to open a command prompt running as Local System?

Solution 4:

Even though this is already answered I thought I would put in my two cents worth becaus eyou can see this same error even if you supply valid paths.

You will get the same error when the process running the watcher does not have access to the remote share. This will happen if the watcher is in a service running under the System account and the share is created by a user. System does not have access to that share and wont recognize it, you will need to impersonate the user to get access to it.

Solution 5:

although you can use a FileWatcher over the network, you will have to account for other factors, like disconnection of the network share. If your connection to the share is terminated (maintenance, lag, equipment reset, etc) you will no longer have a valid handle on the share in your filewatcher