Since I now was googleing for hours without any success I hope I will find an answer in here...

This is the (simpilfied) scenario:

I wrote an application (C#, .NET 2.0) which needs to create and write write some file (more precisely it needs to save an XML document). The application is hostet on a network share and will be excecuted from there. It writes to local drives as well as to network shares. The problem to get the application running from the network share I solved: I signed all assemblys and gave them FullTrust via CAS and an accordingly codegroup. So this works fine.

But the problem I now got is that the application is allowed to create files and write on my local file system without any problems - but when it tries to create a file/write on/to a network share I got an "UnauthorizedAccessException". My Windows user (this one I'm using to log on) has no problems to access the share in any way. The application also runs in my account (at least I think so). It is also no problem to access network files for read access. The problem occures on any network share on any server within my network/domain - and on any share I can create and write new files manually (by using the Explorer for example). There is also no difference if I execute the application from the network or from my local computer.

So - how do I solve this problem Since I'm not yet quite familiar with .NET security topics I would appreciate a comprehensible and some more detailed explanation :-)

Well - WindowsIdentity.GetCurrent() returned exactly the identity I expected to find - my own... Furthermore I asked our admin who told me that most of the file servers I want to access are Samba servers.

But AFAIK Samba emulates the Windows CIFS and SMB protocols - and because I can create files using Explorer this should not be the problem, doesn't it

Rene

You can create new files logged in as the same user, but are you trying to do exactly what the app is trying to do Is it creating new files or editing existing ones

.NET's file access is just a wrapper around the underlying Win32 file APIs. The only extra security it adds is code access security, and it sounds like you're on top of that.

The first thing I'd try is to see if it's something more specific like a problem with ACLs on a particular file or directory - just because you can create new files in the share doesn't mean writes will work anywhere in that share.

Also, try writing a very simple test app that just creates the same files with the same names and in the same places as you tried via Explorer.

If you still find that the behaviour from your .NET code is different, then we'll go from there, but my suspicion is that it's probably not a difference between .NET file access and normal file access - I think it's more likely to be something specific to what you're trying to do with the file.