How to grant ownership of Files and Folders in Windows - c#

I came across a very anoying problem and it took me a while to solve it. Since 99% of the internet was telling me it was not possible and i could not find the answer on stackoverflow i decided to post it here.
I was trying to change the ownership of an folder/file in my windows machine. This is not much of a problem since DirectorySecurtiy has a nice function for it: "SetOwner()". I got this to work for my current account but i could not get it to work for someone else. Everytime i tried to grant someone else ownership i got this error: “The security identifier is not allowed to be the owner of this object”.
// Get folder or creates if not exists
DirectoryInfo dInfo = Directory.CreateDirectory(folderPath);
// Get user
IdentityReference user = new NTAccount(username);
// Set owner
DirectorySecurity dSecurity = dInfo.GetAccessControl();
dSecurity.SetOwner(user);
dInfo.SetAccessControl(dSecurity);
So this code does work if i want to grant myself ownership but not if i want to grant someoneelse ownership. What to do?

After searching the internet further I found the solution in this blog: https://fixingitpro.com/2011/07/08/set-owner-with-powershell-%E2%80%9Cthe-security-identifier-is-not-allowed-to-be-the-owner-of-this-object%E2%80%9D/
It is very strange and i dont know why but if you use unc pathing it will work.
UNC names identify network resources using a specific notation. These names consist of three parts: a host device name, a share name, and an optional file path.
These three elements are combined using backslashes: \host-name\share-name\file_path
So what used to work for myself only: D:\{folderName} had to be: \\{IP or servername}\d$\{foldername}. If you test the exact same code agian only than with a different path it will work. Would be nice if someone could explain me why routing back to your own computer does work by a normal path does not.
Dont forget to run your application as administrator

Related

UnauthorizedAccessException when creating directory but only when impersonating myself

I'm currently running into an odd little problem in an installation wizard. On one single test VM--all the others are fine--I cannot create subdirectories in a directory I created. On the first screen I select an install location and, if it doesn't exist, create it:
c:\Program Files\Foo
Then a couple screens later, I get user credentials for the software to use and, to make sure they have the appropriate permissions, use them via impersonation to create subdirectories under Foo, say Bar and Baz. The impersonation I'm using is based on link.
The thing is, if I'm logged in as myself, that first directory is created just fine. But if I put my EXACT SAME CREDENTIALS into that later screen, it fails to create those subdirs. Despite the fact that it's the same creds that the program itself are currently running under.
Also, as I said, this works literally everywhere else except this one machine. So it doesn't make any sense. All we can figure is something broken about the impersonation system. That's all we can figure. But you'd think it would show up elsewhere. If it was something with the VM, then how did we create the Foo directory in the first place?
Anyway, any suggestions would be most welcome. This is really nutso.
EDIT: I have verified my account is local Admin on the VM. Nothing helpful in the Event viewer. Also, fixed link to MS impersonator code.

Directory.exists returns false for mapped drive in c# coding

I am using Directory.Exists() in my windows service (that is programmed in C#, 3.5 framework)to check to see whether a particular directory exists in the drive. When I run in local machine it works fine, meaning I am able to access the directory.
But when I deploy the windows service on a Virtual Machine, and start the service, it is not able to find the directory even though the directory exists. The directory is mapped on as
Q: drive, Q:\\temp\\local\\ folder
But the windows services always returns false for the Directory.Exists().
However when I give C:\ drive in place of Q:\ it works, but does not work for a mapped drive. I have tried with the UNC path, and I have made sure the mapped drive have the administrative rights and infact the read, write and execute permission. But it still returns false.
Can anyone please tell me why? And how to resolve?
Make sure the drive is mapped under the same user as the Service is running. If you map the drive as user A, it is not automatically mapped for anyone else too.
Mapped drives are only restored during interactive login which services generally do not perform:
Map a network drive to be used by a service
Short version: You can't do it, use the full UNC path instead.
This is most probably a problem with privileges. Your Windows service is probably running under an account which doesn´t have enough privileges to access the network path.
This is a possible duplicate: Accessing mapped folder from a Windows Service written in C#
Another possible solution is to use impersonation, check it out:
http://msdn.microsoft.com/en-us/library/w070t6ka(v=vs.90).aspx
UPDATE
Came to think of it;
Try changing the identity of the application pool to a user with the same rights as your user.
As #Sriram pointed out the Directory.Exists() method will fail if any error occurs. What sort of exception do you get if you try to access the path?
Eg (for both mapped and UNC in case there is something going on there):
DirectoryInfo diMapped = new DirectoryInfo(#"Q:\temp\local\folder");
DirectoryInfo diUNC = new DirectoryInfo(#"\\servername\fnsw\tmp\126");
Note: Assuming that the white space before 'folder' in your path is a typo?
Steps to troubleshoot
Try accessing the network path manually in "Run" [WindowKey + R]
Try to access your map drive i.e.: M:\
Make sure you are the account owner of the mapping (mapping should be done under your account)
Go to Property and see if "Run As Administrator" is unchecked.
Remove mapping and re-add the mapping.
Make sure available offline (or sync offline) is turned off and folder is available from another computer.
Hope this helps!

Application says network drive doesn't exist, but found using OpenFileDialog

I have made a little app that's running on a Win7-PC. All it does, is to check the content of a network drive at 1:00 O'clock in the morning (and compare it to a folder on its local hard drive), and if there´s differences, copy the differences to this folder.
The problem is, sometimes it can not find the network drive.
When the app starts up, the network drive is found using a button on the app which starts OpenFileDialog, and the resulting drive letter is put into a textbox beside the button. From that point it should just run by itself. The PC is never turned off.
When it says the network drive can not be found, I can manually press the button on the very same app, select the drive in the OpenFileDialog (the drive letter never changes), and the app will run flawless in a couple of days. Then the problem occurs again.
The question is: Why can the network drive be accessed through the OpenFileDialog on my app, but my app can not?
My app start the copy-process using this function (called with "Y:\") to determine whether the drive is present or not:
public bool fn_drive_exists(string par_string)
{
DirectoryInfo di_dir = new DirectoryInfo(par_string);
if (di_dir.Exists)
{
return true;
}
return false;
}
...and sometimes it returns a False, until I "wake it up" using the OpenFileDialog.
What does OpenFileDialog do, that my app do not?
According to this SO post, the problem should be gone if you use UNC path instead of mapped network drive.
If your destination has a static ip address, I suggest you use that ip address instead of domain name for network drive
This SO post describes a similar scenario to what you've described.
One of the links posted as a response to that question led me to this MSDN article which provides a variety of reasons as to why one might encounter errors when trying to access shared network drives by using a mapped drive letter.
Microsoft's suggestion (see below) is to simply use a UNC path.
A service (or any process running in a different security context) that must access a remote resource should use the Universal Naming Convention (UNC) name to access the resource.
To answer your actual question more specifically, with regards to why it suddenly can't access the network share, I would venture a guess to say that the network share is being disconnected by Windows due to an idle timeout, as discussed in KB297684. Any attempt to access the disconnected drive will be met with a small wait as the connection to the network share is re-established, which could presumably be what is causing your issue.
To test this theory, try writing some data to a file on the network drive at a relatively short interval (every 10 minutes, perhaps?) to try and convince Windows that the drive is still active.
You can also try to use:
System.IO.Directory.Exists(par_string);
instead of writing Your own method for the same thing. I would expect a framework method to be able to "wake" the network drive.
Note: Method also works for UNC paths (something like \\<server name or IP address>\<shared folder>)
Like Harvey says, use the UNC path to access the folder, for instance \\server\sharedfolder. In place of \\server use the name of the server. Your computer has a name and so does the server. You can also use the IP address if you know it. You replace \sharedfolder with the path to the files. Some examples:
\\AppsServer\c$\Program Files(x86)
\\FileServer1\d$\Users\John\My Documents
The c$ represents that the C drive is the shared folder. If the entire drive is not shared, you will need to share the specific folder. You can do that by logging onto the server, right clicking the folder, and selecting Properties. Then you go to the Sharing tab and check the Share this folder checkbox. If your shared folder is called MyShare, then your UNC path to access the folder will be
\\server\MyShare

Reading UNC path with FileSystemWatcher [duplicate]

I am trying to run a file watcher over some server path using windows service.
I am using my windows login credential to run the service, and am able to access this "someServerPath" from my login.
But when I do that from the FileSystemWatcher it throws:
The directory name \someServerPath is invalid" exception.
var fileWatcher = new FileSystemWatcher(GetServerPath())
{
NotifyFilter=(NotifyFilters.LastWrite|NotifyFilters.FileName),
EnableRaisingEvents=true,
IncludeSubdirectories=true
};
public static string GetServerPath()
{
return string.Format(#"\\{0}", FileServer1);
}
Can anyone please help me with this?
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.
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.
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:
Authenticate first (I use a C# Class to establish a network connection with credentials)
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?
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.
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
You can't use directory watches over network shares, this is a limitation of the OS, not of .NET.

C#: Get folder ownership problem

I am trying to get the ownership of a protected file in C#.
System.Security.AccessControl.DirectorySecurity Sec = new DirectorySecurity(directory, AccessControlSections.All);
is not working for me. I get the error UnauthorizedAccessException. So I cannot change the owner of the file and I cannot edit my access rights. Does anyone know a way how to set the directory permissions?
It sounds like you (or the user that you're application is running under) doesn't have access to the directory that you're trying to get access to.
Mike O'Brien published a nice blog post solving my problem:
http://blog.mikeobrien.net/2009/11/taking-ownership-and-setting-admin.html
This allows me to take over ownership of any folder.

Categories

Resources