I have a very simple task on microsoft IIS (Which means 2 days of configuration hell)
I need to add a virtual directory that points to a different server (Shared folder).
I opened a user in the local and the remote servers and I can see the content of the folder, but when I try to copy something to that folder (from the code) I get access denied.
Of course that the user has a full control (shared and ntfs) but not matter what I'm doing I just can't make this simple task to work.
What have I missed? What should I do to make it work?
Thanks in advance - Tal.
The problem can be solved by changing the appPoolIdentity to a local windows user that has permissions to read\write to the network virtual folder.
The downside (at least from my experience) is performance, the IIS become slow very fast (30 online users in my case).
Related
I was trying to browse a file(S:\Scalable Development\DRD_ToolPointManagement.doc) from shared location trough web browser using application. when I run my application in local, it is working where as if I push the code to dev and QA environment, not able to open a file
There are two different problems, firstly using a mapped drive and secondly access rights to the folder. Both of these depend upon which account the application is running under. Have a look at http://www.iis.net/learn/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis
You need the built in group IIS_WPG which covers the application pool to have access to the network drive. If the S: drive is not mapped on the web server, you will also need to use the UNC path. If you look in Windows Explorer, your S: drive will appear something like
myshare (\\myserver) (S:) which should be translated to \\myserver\myshare\Scalable Development\DRD_ToolPointManagement.doc
Your domain administrator may need to allow access to the network share, and you may need to consider impersonation
When using the Web browser control, you're using the Internet Explorer. Thus, security settings may apply.
You need to change these in the Control Panel's internet settings of every machine you want to deploy to.
For example you may have to add the location to the trusted zone. Also, the target IE may not be configured to open Office documents in-place.
We have an aspx page that needs to check if video files exist on our video server and display a link if the file does exist. However, our videos are not stored on the C drive, but on the D drive instead.
I have tried
System.IO.File.Exists(#"http://ourvideoserver/pcode/videofile_name.mp4") and
System.IO.File.Exists(#"\\ourvideoserver\\D:\\pcode\\videofile_name.mp4")
the last one was just taking a wild guess
And I cannot figure out how to check the files on a remote server on a different drive than C.
Could someone point me in the right direction on how to check in the D drive of the remote server
In UNC paths, drives are represented by a $. That is, D$. Try this:
System.IO.File.Exists(#"\\ourvideoserver\D$\pcode\videofile_name.mp4")
So, something like this should work (it does when I run it as a unit test with a change in the server name).
[TestMethod]
public void CheckUNCFileExists()
{
Assert.AreEqual(true, File.Exists("\\\\fileserver\\documents\\file.txt"));
Assert.AreEqual(true, File.Exists(#"\\fileserver\documents\file.txt"));
}
One thing that you might want to check is the name of the actual share, using an administrative command prompt on the file server (in my case it is the "documents" share):
C:\Windows\system32>net share
Share name Resource Remark
-------------------------------------------------------------------------------
C$ C:\ Default share
IPC$ Remote IPC
ADMIN$ C:\Windows Remote Admin
documents C:\documents
The command completed successfully.
If the path seems ok (and you can get to it with Windows Explorer), another thing to investigate is whether the application pool identity of your web application (probably you if you are debugging on your desktop using something like Visual Studio, or whatever your IIS admin configures on the web server side) has read access to the share (for windows sharing permissions) and read access (via NTFS permissions) on the folder/file (also, depending on how paranoid your admins are, you might also need "traverse" permissions on higher folders).
If you can't get to it with Windows Explorer, and you are using an administrative share (ex c$, d$, etc), you should re-share the folder with a different share name (since this will allow you to change permissions to make it readable by you/and the IIS application pool identity). If you are really bent on using the administrative share name, you'll have to modify permissions of the administrative share and may need to undertake something like this:
http://support.microsoft.com/kb/971277
I've started ut a new instance of a windows server 2008 and am trying to move and launch my web service I've created in Visual Studio. How do I move the project from my local computer to the remote desktop? Grateful for all help!
I've tried the really simple approach and just copied the directory to the remote desktop in the same location as on my local computer. Did not work.. When I try to access the same adress that it has on my local computer (http://localhost:80/somesite all I get is this:
HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory.
I'm probably going about this the wrong way, but don't know where to start..
Sounds like you need to setup IIS. See the following link http://www.codeproject.com/Articles/28693/Deploying-ASP-NET-Websites-on-IIS-7-0
I would make sure asp.net is enabled in the IIS server. Also try to explicitly hit your page such as:
http://localhost:80/somesite/myhome.aspx
I'm sure there is a quick answer to your particular issue, but if you're going to be doing this sort of thing often, it is best to take some time up front and read up, then click around and get a feel for IIS.
http://msdn.microsoft.com/en-us/library/ms178477.aspx
Visual Studio has abstracted much of the site/virtual directory setup and configuration, chances are you can't just copy the files over and have it work. There are lots of things to think about: websites versus virtual directories and their configurations, application pools and their identities, file permissions, default documents, etc. enjoy.
I've got a piece of code that calls the DeleteFile method in the Microsoft.VisualBasic.FileIO.FileSystem class (in the Microsoft.VisualBasic assembly) in order to send the file to the Recycle Bin instead of permanently deleting it. This code is in a managed Windows Service and runs on a Win Server 2k8 machine (32-bit).
The relevant line:
FileSystem.DeleteFile(file.FullName, UIOption.OnlyErrorDialogs, RecycleOption.SendToRecycleBin, UICancelOption.DoNothing);
Of course, I've got "using Microsoft.VisualBasic.FileIO;" at the top of the class and I verified that the method being called is really on the FileSystem class in that namespace. In the above line I refer to a local variable "file" - that's a FileInfo for a local file (say, C:\path\to\file.txt) of which I'm certain that it exists. The application has Full Control over both the file and the directory it's in.
This appears to work just fine as the file disappears from the directory it was in. However, the file doesn't show up in the Recycle Bin. I tried inspecting the C:\$Recycle.Bin folders manually as I suspected the Windows Service running in session 0 would make it end up in a different Recycle Bin, but all the Recycle Bins appear empty.
Does anybody have a clue as to what causes this behavior?
By the way - the machine is definitely not out of free space on the drive in question (or any other drive for that matter), and the file is very small (a couple of kilobytes, so it doesn't exceed the Recycle Bin threshold).
I assume your service is running under a different user account than your own (or one of the special service accounts).
I don't believe it's possible for one user to view the contents of another user's recycle bin - even though you can see some evidence of their existence within the C:\$Recycle.Bin folder.
If it's running under another user account, try logging into the machine using that account, and then check the recycle bin. If it's running under a service account (e.g. Local Service, Network Service, or Local System) it's going to be trickier.
Given that the recycle bins are separate, how are you planning to make use of the fact that the file is in the recycle bin anyway?
the problem could come from the user executing your service, could you try to alter the executing user policy or change the executing user.
Anyway, it could also come from the service being executed without a shell, as the recycle bin depend on the shell api. this post seem to confirm this issue. So you would need to take another approach to acces shell api from your service.
I have one service that will create a text file to local machine and then need to copy the same file to another server .
I am using " File.Copy(SourceFilePath, TargetFilePath, true);"
and getting an exception at the target file path "access denied. I am able to copy the files manually to that location ( TargetFilePath) .
any idea , what is going wrong ??
I don't have any network drive mapping with this target location.
Thanks in Advance
This is a classic permissions issue. You need to make sure that the service is running in the context of a user with the ability to copy files. Since you need to copy files around, I would suggest using a user that is in the Backup Operators group, although you might want something more restrictive for your scenario.
Edit: Since you're also copying to another server, your user will need to have rights on that server as well. For that purpose, you might run your service under a domain account (assuming your machines are both in a domain). You can also test by using the Run As... option on a console app with the same code - that way you can debug permissions issues before setting up the service.
The account that the service is running on must have access to the other machine.
From the source machine can you manually copy the files to the Target?
C:>Xcopy \sourcemachine\dir*.txt \TargetMachine\dir\ /Y/K/D/C
That should help you narrow it down if the problem is related to code or permissions.
If you're not running on a domain, your code can impersonate a user on the other machine that does have rights.