I am using TFS build process with the following MSBuild arguments:
/p:DeployOnBuild=True /p:PublishProfile=Development
The publish profile works when run from my machine in VS, but when it is run from the build server, it fails with this error:
Unable to create directory "\\10.21.8.24\w$\Connector". Access to the path '\\10.21.8.24\w$\Connector' is denied.
This is a FileSystem publish.
I tried specifying the permissions for the user account that the TFSBuildServiceHost service runs as on the target machine.
I've added full control on the entire W: drive, as well as I have created a share on the Connector folder and allowed the read & write access of this user to it.
Another thing I tried was stopping the web application in the IIS management console - but, the error still stays the same.
First, you could double check the account permissions by manually RDC that machine and try to access this \\10.21.8.24\w$\Connector folder using your TFS build service account, ensure this folder can be found and accessed successfully.
Also make sure the Connector folder is writable not Read Only.
Update
w$ is a Admin share.
As “Administrative shares” are defined all the default network shares
that can be accessed remotely only from network administrators. And
there are some firewall settings which may block the connection.
More details please take a look at this blog.
Related
I have several ASP.NET Core Web API services that are deployed via Octopus Deploy (v2019.12.1) to IIS.
I am trying to figure out how the permissions work to the files. When I look at the files/folders, they do not have any any permissions setup on them to allow the App Pool to access them. I don't understand how this works. But I did not care until today when stopped working.
I setup a file share to the Applications folder under the Octopus2 directory. When I did that it all stopped working. My sites now give me an error saying that they do not have permissions to access the config file.
When I look up fixes for this, they say I need to add the App Pool to the file/folder security. When I do this it works... until the next deploy when octopus makes another folder that does not have the added permissions. I could move those permissions up a folder, but then I am moving to manually managing it.
And somehow it worked without giving the App Pool direct permissions. So here is my question:
For an Octopus Deploy IIS Web Application, how does the application have access to the config file? (Assuming you did not do anything beyond the basic template for an IIS Web Application (and supplying a user for the App Pool).
In my case I'm using the custom installation folder where I'm keeping all my applications.
D:\Applications
D:\Applications\Product\Services\App1
D:\Applications\Product\Services\App2
Before any deployment I have a step (required step) in order to set up root home directory as above.
Create Folder step
I'm granting all IIS application's identities ability to access their installation folder.
In case you are using Octopus installation directory you can create child step which will grant desired permission to your application identity.
Application directory:
Octopus.Action.Package.InstallationDirectoryPath
Octopus System Variables
I'm using VSTS to deploy a azure cloud service package and getting a file access issue for web.config not able to be written to after a successful deployment.
At the moment I manually set the file permission via RDP to correct it for eg. on e:\siteroot\1\Web.config (Everyone FC)
To avoid this manual step - how can I set a folder/file permission for a file under cloud service deployment.
The issue seems not related to azure projects directly. It's not suggest to give a permission with Everyone FC, this may cause security risk.
For Azure Cloud Services Web Roles, the default Application Pool Identity account is “Network Service”.
In a normal basis the Application Pool account needs read permission over the web.config file so it can read all the application configuration.
For this kind of issue, you could creating a Startup Task to give write permission to Network Service in the application Web.config file.
Please go through the detail steps in this similar issue: Error “Access to the path ‘E:sitesrootWeb.config’ is denied” when storing Azure AD’s public key in Web.config of an Azure Cloud Services application.
Also take a look at this related question: Web.config Access denied when Package Azure cloud services projects in Visual Studio 2013 for Web
You can create a .bat file where you call the icacls command with the parameters you prefer:
How to grant permission to users for a directory using command line in Windows?
and then you can configure a startup task for your cloud service to run this file:
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-startup-tasks
I use Azure with node js App Service.
When i try to delete empty folder using ftp or kudu app in node_modules folders i get error: 409 Conflict: Cannot delete directory. It is either not empty or access is not allowed. This folder is totally empty. How i can delete it?
Check AppSettings of Web App and delete the setting ‘WEBSITE_RUN_FROM_PACKAGE’ or changing the setting value to 0.
0 - write mode;
1 - read-only mode
All Azure Web Apps (as well as Mobile App/Services, WebJobs and Functions) run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available. For more details, refer to this article.
For directory level access please refer the below:
Home directory access (d:\home):
Every Azure Web App has a home directory stored/backed by Azure Storage. This network share is where applications store their content. This directory is available for the sandbox with read/write access.
The sandbox implements a dynamic symbolic link in kernel mode which maps d:\home to the customer home directory. This is done to remove the need of the customer to keep referencing their own network share path when accessing the site. No matter where the site runs, or how many sites run on a VM, each can access their home directory using d:\home.
Local directory access (d:\local):
This is a temporary directory and can be deleted when no longer needed. This directory is a place to store temporary data for the application. The application naturally has read/write access to this directory.
Note that the d:\local folder in the scm site (where Kudu runs) is not the same as the one in the main site (where the web app runs). As a result, they cannot see each other's local files.
Incase if you haven’t tried this already, use the rmdir directoryname /s /q command in Kudu Console to delete the directory and see if that works.
You can also run this command from Web App console. To access, Goto Web app -> Development Tools -> Console
Hope this helps.
There is a Process explorer tab in the header.
Open Process explorer
Kill the task that's using the folder or file
You will be able to delete the folder in question
This is how I resolved the same issue.
Here is my solution: adding this option to your step deploying to the app service.
Hope it would help
You may use the command api to do that. Craft a CMD or PowerShell command that'll clean your wwwroot and then execute it.
I tried all of the upper solutions and didn't worked. Blackhole!
I stopped the app service, removed the files and started again. It worked.
I have two azure entities I'm trying to connect, a build agent running my nuget deployments and a VM (Windows Server 2012 R2) on which I'm trying to set up symbol hosting using SymStore.
From this page I am told to Grant full control permission to the build agent service account. How do I go about doing this? In the Publish Symbols build step, I can enter a URL to store the symbols, but I have no way of logging the build agent into the VM as the user that I've given full control permission to.
This setup is actually not possible; from the SymSrv docs: writes to an http-based symbol store are not possible.
It appears that the SymStore has to be on the same machine as the Azure build agent to give it full control permission. I happened to discover that NuGet will let me publish .pdbs, so I'm going to try that route instead.
I wish to have an automated process that basically deploys (copies) a asp.net web site in a CI situation. I have built the web site and I then want to copy the code to the web server. This powershell code is running on my build server. the build server is running under a defined service account and i have given that account full control to the folder on the web server where the web site needs to be deployed.
The powershell code works if i run it from my local machine under my accoount (i have full control). When I run the code from the build under my admin acount it fails. when it runs under the service account it fails.
The web server and build server are both windows 2003 boxes. My machine is Vista.
I am really confused here it seems like the user credential are not correctly getting passed from the build server to the web server, but are from my vista pc to the web server. I wish our admins had a clue, this seems like some very basic authencitaions issues.
commands that a failing are Copy-Item and Remove-Item, I can do get-childitems no worries as i am copying all the existing file into a zip before i re-deploy (ie i can access the folder i just can write)
Thanks in advance
RhysC
See this:
PowerShell 2.0: Accessing Windows Shares during a Remote Session
I know you mentioned that Get-ChildItem was not failing, but what are the read rights (share and file-system) on the WebServer?