I've written a console app to help load code to servers, but I'm running into an issue running it. I'm getting a "System.UnauthorizedAccessException: Access to the path '\...' is denied.
The app is comparing files, and those that are different it copies from a staging area to the server. It runs fine until I try to copy, then I get this error (e.g. I can read and compare the files, but not modify them). If I (manually) simply copy a file from one area to the other, no issues.
I was under the impression that a console app runs as the person who executes it.
The offending code is this:
File.Copy("correct staging path", "correct live path", true);
I was able to verify that the application is running as me using:
Environment.UserName (WindowsIdentity.GetCurrent().Name shows the same)
The destination path is a network share (e.g. \\servername\path)
Related
This is not actually my own code and I don't have a way to change and compile it, but I'm trying to debug a program and all it does is download a file and store it locally. It's literally something like:
try {
using var client = new WebClient();
client.DownloadFile( URL, filename );
log("File successfully downloaded");
}
catch (Exception e) {
log("Download failed.");
}
URL and filename are passed as arguments so I can actually change those. If filename is a local path, like for instance "/home/myusername/test.dat", it works fine. So I know the code works. But if filename resides on a mounted NAS (ie "/mnt/NetworkDrive/test.dat"), it gives the "Download failed" error.
It looks like the user the code runs under, does not have write permission to the mounted network share. But I mounted the network share with the noperm option, and creating files manually always succeeds, no matter what user I try it as.
The network share is mounted through /etc/fstab:
//192.168.1.131/sharedfolder /mnt/NetworkDrive cifs guest,_netdev,vers=1.0,noperm 0 0
Where 192.168.1.131 is ofcourse the IP address of the NAS. It's an older NAS which uses SMBv1 which is why I mount it with "vers=1.0" And like I said, I can access the NAS just fine. I can create files and delete files from the command prompt without problems. As any user. But the above code fails to write to it.
What could be causing this?
Again, this is not my code so I can't change anything. But I'm sure the code is fine and something else is at play here.
UPDATE #1 (Mar 31)
So it turns out writing to the NAS is denied, which is weird because if I test it (from the command prompt), I can create and write to a file on the NAS without problems. As root or any other user.
UPDATE #2 (Mar 31)
I've been troubleshooting all day and I'm at a loss. Any user has full access to the NAS and can read/write/delete/create/modify files. I can create a new user on the system and it too has full access. But WebClient.DownloadFile always fails with a "Permission Denied" as soon as it tries to write the downloaded file to the NAS. If I write it to a local path, it works fine.
I have a web service that is trying to write a file to a file share.
The application pool for the site in iis is running as a custom domain account: "domain\domainaccount"
I'm operating under the assumption and hope that when the code tries to write the file it will use the "domain\domainaccount" user to do so.
Executing the following line of code produces the error: Access to the path [filename] is denied
FileStream stream = File.Create(fileName, result.Length);
I have confirmed that the "domain\domainaccount" account has access to [filename] which is the full path of the file including the file name. I have even given the account access from the very top of the share structure, not just the specific folder the file needs to be written to. In fact, if I run notepad as "domain\domainaccount" I can save a file to that exact location.
What might I be doing incorrectly? Is it not using the domain account to write the file? If not, can I change something so that it does?
I should note that if I log into the iis server and run the web service from there, I do not get the access denied message and the file is created.
I tried to create a C# Windows Forms tool to copy entire content from my local machine to another machines on the domain.
The problem that most solutions to copy just file not entire directory is not working.
I can't using Impersonation to change user context and then use File.Copy() to copy content cause the users on the remote machines different than the user on my local machine.
using ( new Impersonator( "yourUsername", "yourDomain", "yourPassword" ) )
{
// The following code is executed under the impersonated user.
}
Also to use File.Copy() like that:
File.Copy(
#"C:\Users\user\Desktop\file.txt",
#"\\remote\Users\user\Desktop\file.txt"
);
the remote path should be a shared path, and this is not the case here as i have a credentials to servers but want to copy the directory to specific not shared location.
I found another solution that uses PSexec tool to activate listener on the server and then send files to it from my local machine (Socket programming) but it's not stable: you can find it here
I also think about writing a powershell script that can do that and i run it from my C# program.
So is it another solution for doing that in a correct way, Copying entire directory/directories from local to remote machines.
I am developing a Windows Phone 8 application but am having a lot of issues with file access permission exceptions hindering the approval of my application when ever I try accessing files in the "local" folder (this only happens after the application has been signed by the WP store, not when deployed from Visual Studio). To solve this I have moved all file operations to IsolatedStorage and this seems to have fixed the problems.
I only have one problem left though. My application needs to make use of the file extension system to open external files and this seems to involve the file first being copied to the local folder where after I can then manually copy it into IsolatedStorage. I have no problem in implementing this but it seems that a file access permission exception also occurs once the system tries to copy the external file into the local folder.
The only way I think this can be solved is if I can direct the system to directly copy into IsolatedStorage but I cannot figure how to do this or if it is even possible. It seems as if though the SharedStorageAccessManager can only copy into a StorageFolder instance but I have no idea how to create one that is directed into IsolatedStorage, any ideas?
PS. Do you think that the Microsoft system might be signing my application with some incompetent certificate or something because there is not a hint of trouble when I deploy the application from Visual Studio, it only happens when Microsoft tests it or when I install it from the store using the Beta submission method.
Below is a screenshot of the catched exception being displayed in a messagebox upon trying to open a file from an email:
EDIT:
Just to make it even clearer, I do NOT need assistance in figuring out the normal practice of using a deep link uri to copy an external file into my application directory. I need help in either copying it directly into isolatedstorage or resolving the file access exception.
Listening for a file launch
When your app is launched to handle a particular file type, a deep link URI is used to take the user to your app. Within the URI, the FileTypeAssociation string designates that the source of the URI is a file association and the fileToken parameter contains the file token.
For example, the following code shows a deep link URI from a file association.
/FileTypeAssociation?fileToken=89819279-4fe0-4531-9f57-d633f0949a19
Upon launch, map the incoming deep link URI to an app page that can handle the file
// Get the file token from the URI
// (This is easiest done from a UriMapper that you implement based on UriMapperBase)
// ...
// Get the file name.
string incomingFileName = SharedStorageAccessManager.GetSharedFileName(fileID);
// You will then use the file name you got to copy it into your local folder with
// See: http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.storage.sharedaccess.sharedstorageaccessmanager.copysharedfileasync(v=vs.105).aspx
SharedStorageAccessManager.CopySharedFileAsync(...)
I've inline the information on how to do this from MSDN http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206987(v=vs.105).aspx
Read that documentation and it should be clear how to use the APIs as well as how to setup your URI mapper.
Good luck :)
Ok I figured it out. The "install" directory is actually restricted access but for some reason the Visual Studio signing process leaves the app with enough permissions to access this folder. The correct procedure of determining a relative directory is not to use "Directory.GetCurrentDirectory()" but rather to use "ApplicationData.Current.LocalFolder". Hope this helps!
I've written a Windows Service in C#/VS2008/.NET3.5 that monitors some FTP directories with FileSystemWatchers and moves the files out to another location for processing. I noticed today that it throws errors stating "The parameter is incorrect" soon after the service has started up, but if we wait a few minutes the file gets copied without incident. I saw that the error message is often related to incorrect permissions, but I verified permissions on the directories (target and source) were correct and as I said the file move works just a few minutes later.
Here's a snippet of the code that gets called when the file is finished copying into the FTP directory being monitored:
//found the correct source path
string targetDir = dir.TargetDirectory;
string fileName = Path.GetFileName(e.FullPath);
errorlocation = "move file";
string targetFilePath = Path.Combine(targetDir, fileName);
if (File.Exists(targetFilePath))
{
File.Delete(targetFilePath);
}
File.Move(e.FullPath, Path.Combine(targetDir, fileName));
dir refers to and object with information about the directory the file was being loaded into. e is the FileSystemEventArgs. Targetdir is grabbed from the directory's settings in a custom configuration block in the app.config that tells the service where to copy the new files to.
I didn't include the code here, but I know it's failing on the File.Move (last line above) due to some EventLog entries I made to trace the steps.
Any idea as to why the move fails soon after the service startup, but works fine later?
Basic overview of the process in case it sheds some light: external vendors FTP us a number of files each day. When the file comes in, my code identifies who the file is coming from based off the FTP directory and then loads settings to pass on to SSIS jobs that will parse and save the files. There are maybe a dozen or so directories being monitored right now each of which has its own configuration setting for the SSIS job. Is it possible that the system gets confused as startup and just need some time to populate all the settings? Each source directory does have its own FileSystemWatcher on it.
Thanks for your help.
The first question I'd answer is, what are the values of these when it fails:
e.FullPath
targetDir
fileName
chances are one of those values isn't what you expect
I'm marking this answered because the problem went away. We haven't changed anything in the code, but it now works immediately after restart. The best theory we have is: since I posted this, the client I was working for moved offices and as part of the migration a lot of system and network policies were updated and server setting tweaked for the new environment. It's likely one (or more) of those changes fixed this issue.
Further support for this theory: prior to the move my development VM could not run web browsers. (I'd click to load the browser and it wouldn't work, sometimes it would appear briefly in Task Manager and then disappear.) After the office move, this problem no longer occurs.
So it was likely some network setting somewhere that caused issues. Sorry I can't be more specific.