CODEWITHSUNDEEP
vb.netwcf.net-4.0windows-servicesaccess-denied
Smudge202
Smudge202

Reputation: 4687

System.UnauthorizedAccessException - Access to Path Denied

This is a slightly tricky one, so bear with me...

I have a simple little method:

Public Overloads Shared Function DoStuff(ByVal path As String) As Boolean
        If Not IO.File.Exists(ipath) Then Throw New ArgumentException

        Dim result As Boolean
        Using fs As FileStream = New FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read)
            ' do stuff here, details are not important
            fs.Close()
        End Using

        Return result
    End Function

I appreciate that the method does not show how the stream is used, but the details are irrelevant as I'll explain below.

This method is sat snuggly in a Class Library; a Helper which we reference in a variety of other projects. Clearly, for the most part that code should look fine on the assumption the path is valid, accessible, etc.

Now, the issue. I have a WCF Service Library that references and consumes the aforementioned Method in the Helper assembly. The WCF Service Library is hosted within a Windows Service, which in turn resides on one of our servers. The WCF Service has an Operation that receives a UNC Path for a file, and during normal flow, calls the method above in the Helper Class.

The path I send is for a file, on a share, on our network. The line "Using fs As..." fails with the following exception:

System.UnauthorizedAccessException: Access to the path 'my file path is listed here' is denied. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode) at MyHelperAssemblyName.DoStuff(String filePath) in the rest of the exception is a stack trace pointing to the method, assembly, wcf service, etc"

Now, a list of things I have tried to diagnose the issue (including the stupidly obvious steps):

Upvotes: 11

Views: 13761

Answers (4)

user170934
user170934

Reputation:

I have a few hunches.

Have you tried setting 'FileAccess.Read' and/or 'FileShare.Read' to 'ReadWrite'?

Also, is it possible this warning could be a factor? From http://msdn.microsoft.com/en-us/library/5h0z48dh.aspx:

Caution

When you compile a set of characters with a particular cultural setting and retrieve those same characters with a different cultural setting, the characters might not be interpretable, and could cause an exception to be thrown.

Upvotes: 1

Alex Peck
Alex Peck

Reputation: 4711

Does your WCF Service use impersonation?

This would explain why the new windows service can perform the action but the WCF service could not. The new service authenticates directly against the NAS. If in the old service, WCF were impersonating the caller, the client computer authenticates the user, their token is passed to your WCF service, which in turn passes the security token to the NAS, and you hit the double hop problem.

You can make the active security context revert to the service account like this:

using (WindowsIdentity.Impersontate(IntPtr.Zero))
{
    DoStuff();
}

Of course, this doesn't explain why it might have been working intermittently. But it would explain the WCF service working when invoked locally on the machine that is hosting it, but not from a remote client machine.

Upvotes: 1

Mike
Mike

Reputation: 3460

Try process monitor. It will show you what user is accessing the file and the specific windows error code that is being returned. Then you should be able to see why it is working for some files and not others.

Upvotes: 4

Fabio
Fabio

Reputation: 730

I had something similar when my code was accessing a new file which wasn't yet fully written to disk. So waiting a few milliseconds solved it for me. Is it possible that you are trying to read that stream before it's being completely written to disk?

Upvotes: 1

Related Questions