Our department is in the process of moving to a new domain. We were all given new network logins etc. Our computers are part of the new domain, everything seems to be ok. I've copied all my files over, but when I run visual studio, I get the classic error...
Could not load file or assembly 'AjaxControlToolkit' or one of its dependencies. Access is denied.
Now, I know this is a permissions issue, and I assume it's happening because I'm running visual studio as a different user, and the file permissions need to be redone. I've tried adding and granting full access to c:/users/myNewNetworkID/appData/temp for IIS_Iusers, Network services... I remember when I started this job and the PC was new that I had to change a bunch... does anyone know exactly what folders need to have new permissions assigned? I also tried granting those users full access to the temp asp.net folder in Microsoft.net/framework64/... but I'm still getting this infuriatingly vague error. any help would be greatly appreciated...
I've had this problem before and have found that granting full control to the group called "Everyone" for the folder C:\WINDOWS\Microsoft.NET\Framework[.NET FRAMEWORK VERSION]\Temporary ASP.NET Files does the job although your error could be caused by something else. The folder above is where temporary files are stored when apps are compiled for the first time (this will probably include a shadow copy of the Ajax Control Toolkit listed in the error above) are temporarily stored
Find this folder in Windows Explorer, right click on it, select properties, go to the security tab, grant access to the 'Everyone' group)
Related
Our asp.net app writes errors to a text log file in the web sites root folder. This has lead to all sorts of permission problems, different flavors of IIS and windows allow different things by default.
So what I am wondering is there a location somewhere in Windows where all types of users can write a file without any extra permissions that will also work for all IIS and flavors of windows?
I am thinking of the ApplicationData folder, but did this exist in Server 2003 ?
Thanks,
AJ
The easiest solution would be to use the App_Data subfolder of your web application for this. By default it's not viewable from the web, so Internet clients won't be able to read the logs.
Depending on your deployment method, you might have to change the permission to allow write access to this folder (to the user under which your web application is running).
Alternatively, there is a place where every user can write to: It's that user's temporary folder, which you can access through Path.GetTempPath. This, however, does not sound like a suitable location for log files.
You should always first think about wwwroot folder (%systemdrive%\inetpub\wwwroot) because it has the required permission.
The permission you need is to set a full control for IIS_IUSRS
Edit: you can simply give Everyone Full Control (not recommended at all) but this solves most of ntfs permissions issues with IIS
I've just installed windows server 2008 r2 along with visual studio and dropbox. I'm using it as a VM for development and dropbox helps me keep my files in sync with other machines.
I've got my site set up in IIS but I'm getting an access denied error when trying to view the site. I've had this before and to get around it in the past I've gone through and added the IIS_User account to the list of permissions to read/modify the files. I assume because the file's have been copied down with drop box the files don't have the necessary permissions. Here's the bugger, I can't batch update the files by modifying permissions on a folder, I'm having to do it right to the file level and even worse, one at a time! I can't have this.
I'm relatively new to 2008 r2 and IIS 7 so I have no idea what's happening here. Can someone explain what is going on and if there's an IIS/file permission setting I can update to resolve it at the top level folder?
I've tried adding anonymous permssions on the website in IIS and I've added permissions on the folder for IIS_User (even Everyone). I have an Administrator account and that's already set to allow me to read/write/modify the files.
This is typically the message I'm getting 'An error occurred loading a configuration file: Access to the path X is denied'.
This is happening on ascx & aspx files as well as config files.
Edits:
The site is visible when debugging from Visual Studio.
The site is operating in Full Trust (internal)
Please help, this is stopping me from working and driving me insane!
By default in IIS 7, websites run as the local system's network account (NetworkService), not as IIS_User.
To verify, in IIS Manager, select the Site in question, click Basic Settings... and check the Application Pool it is assigned to. Then go into Application Pools and check the Identity for that Application Pool. Make sure that user listed is in the ACL.
Adding Everyone to the ACL should work instead, but just in case I would suggest you check the above. Also of course make sure when you set the ACL to check the box for resetting inheritance on all subfolders, if that is appropriate for your application.
You could also try setting the identity of the application pool to a local (or domain) user you have created which has access to your application directory.
Hope that helps.
Regarding whether other identities would work for your app pool, that depends entirely on whether those identities have permissions to all the files and/or databases and other resources you application needs to access. Right now you have the application running under your user account, which is generally not recommended. IIS has your password cached, and if you change it, your application will stop working until you update the application pool configuration.
As far as setting NTFS permissions, it can get tricky. Once you have disabled permissions inheritance, that file or folder will need to be updated individually every time you need a permission change. The flip side of this is that you cannot remove inherited entries on an ACL, you can only add to them. However you can design a strategy that offers a baseline level of permission at the root of a file structure, and then add permissions to subfolders/files.
In order to check & reset inheritance on a folder, go into its properties, security tab, click advanced, then click Edit. You can see whether this folder inherits permissions from its parent, and optionally wipe out all subfolder/file permissions and enable inheritance on all child folders & files.
Hope this helps.
We can run the ReportViewer in a ASP.Net Web App project that is off the root OK so localhost/test/report.aspx works. It's running as a Client Report. But if we move the application up another level the report stops working so localhost/testfolder/test/test.aspx.
When the report fails it has no data to display and none of the images are loading.
Info: We are bind the report in code and sort out the Report.LocalReport.ReportPath to the correct path.
Can't help thinking there is a setting wrong, but stumped at the moment!
From the comment I've probably not made my self clear, the ASP.Net WebApp is not at the root level it's at the. There is the root application, then "testfolder" as an application and then "test". There are no access permission problems for the files.
Could you please give proper access permissions to new folder. I guess there would be report viewer user/group to give permission.
What I have?
I have a ASP.NET page deployed in layouts folder of 12 hive in SharePoint. This page makes use of Accordion control in AjaxControlToolkit.dll V3.5.40412.2.
I have placed the page code behind class assembly and AjaxControlToolkit.dll in Virtual Directory bin folder.
What I want?
I want to load this page when a link clicked from a web part for users of "Visitors" site group when the DLLs are placed in virtual directory bin folder.
What problem am I facing?
The page loads properly for administrator. But, for "Visitors", it shows "The website declined to show this webpage" error message.
In these scenarios the page works fine for "Visitors":
If I place both the assemblies in GAC
If I give Everyone read permission to AjaxControlToolkit.dll (in bin)
Am I missing something here?
Update: One strange thing I noticed was I removed everyone read access to the DLL and given one of the users in "Visitors" group read permission to the DLL. Then, I tried to login with that user and it works fine for him. But, now, it is working for all the users in "Visitors" group. I am surprised! When I removed the user read permission again same error repeated for all the users. How can it happen?
DLL's that are placed in the bin folder do not run uner Full Trust, you need to create a Code Access Security (CAS) policy file and deploy that to your sharepoint application. CAS policies are used by the .NET framework to assign execution rights etc. to (specific) dll's.
More info here.
No matter what I do such as give Network Service and the ASP.NET account full rights to the folder that contains the image, I am still getting this error for a System.IO.File.Move. Anyone know what other accounts I may be missing here? Network Service is the account running the app pool under which this site runs on and I gave Network Service full rights to the entire folder.
I've tried everything. I gave Network Service and the machinename\aspnet full permissions to the folder that contains this .jpg. I'm testing this code and this move on localhost...my developer machine.
Have you tried using SysInternals FileMon now part of Process Monitor. You can use it to watch for the file access events or the access denied event.
It might be because you write into some other folder that is not under the ASP.NET application (eg %TEMP% folder or something). In this case the account used is IUSR_MACHINENAME which represents anonymous user.
You either need to impersonate, use another folder or give write privileges to IUSR_XXX (which I don't think is a good idea) to deal with that.
On the machine hosting the shared drive, make sure to set things up under both these tabs:
Sharing -> Permissions
Security
Most of us deal with the Security tab for getting IIS stuff working, but it was the former that was giving me the same issue with the .MoveTo() method. (It could read, just not move).
To further complicate matters, I also had the directory shared as multiple names - make sure to check the permissions for each shared name.