I have a dll that opens a file for processing. It attempts to find the file with FindFile() function. I also have a service that calls the dll and here is the problem - when the path to the file is a network path, FindFile() fails to find it but only when called from the service, if I call it directly from my application it finds the file. I'm sure the FindFile() function gets the same parameters in both cases as I write a log file with it. Parameter looks like this:
"\SERVER\SERVER_USERS\USERX\TEST.TXT"
I know this is 6 months after the question, but I figured I'd answer it anyway ... Usually, it is a permissions thing. If the service does not have access to the network folder, then it won't find anything. Many services run as a local system account by default, and that account doesn't have built-in access to network files. So try making sure the service is running as an account that has access to the network folder in question.
Related
We're working on validating our Loupe service to run as an Azure App Service and have run into a showstopper we can't figure out. Anything that attempts to resolve a temp directory fails with the exception:
mscorlib : System.IO.IOException
The directory name is invalid.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.__Error.WinIOError()
at System.IO.Path.InternalGetTempFileName(Boolean checkHost)
The stack trace has this within the .NET method for generating a temp file name. This stack trace is common to pretty much all the areas we get the failure. For a bit it seemed that if we forced the site to restart and/or forced the underlying App Service Plan to rescale it would go away until we next updated the site but no longer.
Since the only search results we could find said this error happens when impersonation is enabled and the user the site's impersonating doesn't have access to the IIS App Pool user's temp directory we've dug into that. First, we can confirm from our logging that the thread is not impersonating at the time the failed request is made. Second, just for fun we added this to the web.config to be doubly sure:
<system.web>
<identity impersonate="false"/>
</system.web>
All to no avail. If this was a generic problem with Azure App Services then I would presume it would break many systems, so I have to conclude we've done something fascinating and wrong to cause it.
This might not be the exact answer you're looking for but it might help point you in the right direction.
I had similar issues a while back using the Azure App Services. I found that accessing the local file system was somewhat problematic. Sometimes it worked fine and other times it didn't.
Eventually, I discovered that when an Azure App Service is instantiated, it doesn't always use the same drive letters for the system behind it. In some cases, this can cause the environment variables to be blatantly incorrect. They "think" they are set properly, but that's not always the case.
Generating a temp filename will use that environment variable for the path and if it's set to C: but the machine has a D: drive instead, if will fail. The C: drive doesn't exist and therefore the path to the temp file can't exist either.
To identify if this is the problem, you need to enable RDP so you can log into it directly. https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-role-enable-remote-desktop
It's the only way I was able to eventually figure it out.
If you open up the Kudu instance for your App Service Web App you'll be able to see what the local Temp directory is on the Managed VM underneath. You can access Kudu by going to "Advanced Tools" on the App Service blade in the Azure Portal, or by navigating to the https://{web app name}.scm.azurewebsites.net domain for your Web App.
Once in Kudu, click on Environment in the top navigation. The Temp directory is usually D:\local\Temp and that path is stored in the "TEMP" environment variable made accessible to your Web App.
Given we have some Hadoop MapReduce task to be run. This MapReduce needs to access some system resources on local drive, i.e. on some node (in fact, we have to place that resources to all nodes).
A question is: which permissions should be given to that resource file?
I would like to give it permissions to be read by the user which runs Hadoop. But in fact the task will be executed under another user. That user is 'yarn'. I.e. if I want to place some resources to some home folder of user which runs Hadoop Job, or related Oozie job etc I cannot do it because in fact home folder of the user which owns MapReduce is /home/yarn/.
What is the best way to deal with this issue?
How do I control under which user MapReduce runs?
Where can I lookup that settings?
I guess all you need is to create the required folders for such resources in HDFS, and set the permissions to those folders and the contained files using 'hadoop fs -chmod ..' command.
Please refer this below link:
https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html
First off the statement "MapReduce needs to access some system resources on local drive" is not possible when running a MapReduce program in distributed mode. Whatever file you need should be moved to HDFS. Give the file a read permission to all users I hope everything should be fine. If you need to read the file in the Mapper or Reducer and not pass the file as the input to the MapReduce program then consider using Distributed Cache mechanism provided my MapReduce.
i want make a new directory in application server in sap system ,and send my file in it .
for sending file in existing directory i find and use this transaction
CG3Z :/usr/sap/R3D/exe .
But i can not find a solution , neither with transaction nor abap codes .
I know that we can see directory with AL11 but I want to make my own directory.
I searched in SAP SCN and Stackoverflow but have not been able to find any similar problem.
Usually this is NOT done by application code but by a system administrator - otherwise you would have to add provisions for all supported operating systems. Also, there are a lot of other issues to take care of, like setting the proper file system permissions or making sure that a DFS is available on all application servers (writing stuff to application servers randomly depending on which server the user was logged on to usually won't do you any good). Have your system administrator setup a logical file name for you and use that.
We are using Tridion 2011 SP1. Some of the pages/components are getting failed while publishing with below mentioned error.
Phase: Deployer Prepare Phase failed, Unable to unzip,
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process),
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process), Unable to unzip,
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process),
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process)
Components/Pages are failing under stage Preparing Deployment, how should we fix it?
Do you have multiple Deployers using the same incoming location?
It looks like you’re running the Deployer as a WebApp – is the Deployer service also running on the system?
If you search for all files named “cd_deployer_conf.xml”, do they have the same incoming folder (D:\Inetpub\TridionPublisherFS4SP\incoming) defined?
Otherwise, you might use ProcMon to watch the folder and see what else is accessing the file.
If you still have this issue, you may try
1. deleting all files under incoming,
2. making sure there is no encryption enabled for the incoming folder (Some companies apply encrypt script immediately to the files that are added to the drive) or
3. making sure your antivirus is not screening that folder (As Nuno mentioned).
Do a restart of the deployer app and verify in the logs?
Needed to write a server text file as the output of a business process initiated by ASP.net app.
The text file writing code is in a library file using standard stream code
All worked OK in IDE.
Publish and it falls over trying to write file. IIS is reluctant to write to the file system.
Much rummaging around and hair pulling finally led to a solution. It is not pretty and only applicable in a situation where you have control over the Webserver.
Just saw your answer.
It doesn't need to be inside your inetpub or wwwroot directory for that matter, it could be anywhere, as long as security permissions are set correctly for the user under which the application is running as.
But this is actually desired. If not just imagine the consequences of allowing write access anywhere.
Also, there's no need for the virtual directory. You could create a directory like C:\ProcessOutput, and grant permissions accordingly and it should work just fine.
Another option, would be to have a service account created, and impersonate as that user within your application only for when you need to write that output file.
Solution was:
Create a physical directory on the webserver with the physical path of:
c:\inetpub\wwwroot\mywebapp\myOutputFileDirectory
Make a virtual directory that points at the directory.
Using windows explorer give write permission to the physical directory to IIS_IUSRS.
Use a physical path of c:\inetpub\wwwroot\mywebapp\myOutputFileDirectory in your Streamwriter code
Maybe the virtual path could point to somewhere more sensible across the LAN if you get the security sorted but I am sufficiently battered to accept this small crumb with gratitude.