I am getting this error message running a batch job with TeamCity. The batchjob is copying files from TeamCity Server to another server(server2). Have checked multiple times, the folders have all the rights permissions needed and this works fine (copies files between servers) when the batch job is run manually from command prompt. I have this error for each file that needs to be copied.
error MSB3021: Unable to copy file "..\bin\Release\Boo.Lang.Compiler.dll" to "\Server2\DestinationFolder\". Could not find a part of the path '\Server2\DestinationFolder'.[10:54:32]: Creating directory "\Server2\DestinationFolder".
I tried few things, but issue remains unresolved. Thanks for your input.
TeamCity build Agent is running as System user account that has no access to the network resources, you should change the service user to an account that has network permissions, like your Administrator account.
See also the related question.
Related
I have an SSIS package that runs a backup in a T-SQL task and then uploads the file to google drive from an execute process task. The package runs perfectly from the catalog. When I try to run it from sql-agent job, the backup runs ok but the upload to google drive does not. There are no error messages in the job history or in the package history.
The sql agent job is set to run from a proxy account with the necessary credentials.
The issue turned out to be that the command file was trying to find another file it needed to run execute the code, but since the windows user changed it was looking in a different users folder. We solved it by passing the filepath as a param so it doesn't default to the user accounts folder its executed from.
I have a simple batch file which needs to be run weekly to upload some files via Core FTP.
I'm using the free version of Core FTP LE.
MySavedProfile is the Site Name of the saved profile I created using Core FTP's site Manager. The profile contains the URL / credentials / etc of the site to connect to.
Here are the contents of the batch file:
SET logf=confirm.log
echo test-start >> %logf%
"C:\Progra~1\CoreFTP\coreftp.exe" -B -s -pasv -O -site MySavedProfile -u "C:\Progra~2\PathToFiles\FileToUpload.txt"
echo test-finish >> %logf%
For the Windows Server 2012 r2 Task Scheduler, I have created a basic, weekly scheduled task on the Task Scheduler Library root which runs the batch file. For this scheduled task I have:
(Under the General tab)
"Run whether user is logged on or not" is selected
"Run with highest privileges" is checked
Configure for = Windows Server 2012 R2
(Under Actions)
Action = Start a program
Program / Script = "C:\Progra~2\PathToFiles\batch.bat"
Start in = C:\Progra~2\PathToFiles\
Here is the weird behavior I am getting:
If I double click on the batch file directly, it works fine and uploads the text file via Core FTP just fine.
However, if I try to let the Windows Task Scheduler run it, it runs everything except the Core FTP line. That is, I get the usual:
test-start
test-finish
in the confirm.log file, but the FileToUpload.txt has not been uploaded to the remote server, and there are no errors from CoreFTP that I can detect.
I have tried this with a service account that has permissions to run batch files, as well as my own account for this scheduled task. I get the same result: it doesn't seem to run that CoreFTP line. At least not via Task Scheduler. I need this upload to be automated.
I've searched Core FTP's documentation, Google, etc. No one seems to have run into this exact issue. I've applied recommendations from distantly related issues, but none of them have worked.
Any help would be greatly appreciated. Thank you.
The only way to do this is to use the full version of Core FTP (that is Core FTP Pro). If you use the LE version you have to check the "Run only when user is logged on" option.
This happens because of the splash screen at the beginning.
If you can't be logged on forever you could create a user that will always be logged on just for these tasks.
Remember to use the -Log option on CoreFTP to check if it is actually doing something.
I have built a windows batch file code that fetches the list of files from an FTP server and then pulls the appropriate file from that list. The batch file uses a combination of pscp.exe and psftp.exe in order to achieve this.
If I login as a member of the administrator group and execute this batch file manually (double clicking) it works perfectly, but the problem arises when I schedule a windows task to run that batch file from a windows service account (which is not in the administrator group).
The job when running under the windows service account is unable to execute the command for pscp.exe used in the code, whereas it executes everything else prior to that in the batch file perfectly normal.
Below is the line of code that I have used in my batch file :
pscp.exe -sftp -v -batch -pw %password% -ls %username%#ServerAddress:/outbox > F:\dirlist.txt
The service account is a member of BatchAccountsLG and ServiceAccountsLG groups, which is needed for the job to be able to execute the batch file code. Also, the service account has all the required access on any of the files/folders needed in the execution of the code.
I am not sure what the problem is because the batch file works perfectly fine if use my admin credentials, whereas it fails when the job is scheduled with the windows service account.
I have tried looking for an answer through google, but I have drawn a blank, any help on this would be highly appreciated. If there is anything else that I need to add to this, I would be more than glad to do so.
Thanks to all the ideas in advance.
What is the default SSIS Account that is used in SSIS packages.
In one of my packages I have a Data Flow task that creates a flat file. A BAT file later runs and creates a file based on information in that .txt file. If I execute the .BAT in Windows Explorer it runs fine. When SSIS tries to execute it I can see the CMD window open and it tries to access the txt file and isnt able to. Says "Unable to access nameoffile.txt"
I assume the issue is that the permissions are probably inherited by the SSIS user account so I am trying to figure out which account that is.
If you are running it from the IDE then it uses your permissions. Most likely the problem is that your file is locked by some other process in your SSIS package. To verify:
Add a PAUSE to your batch file to make it wait for any key.
Run your package. While the dos prompt is waiting, go into windows explorer and run your batch file again - you'll find the same error.
I changed the attrib value in dos for that specific folder by attrib -r -s and it worked. It thought it was read-only.
I am using Windows Server 2012 server, with a SQL Server 2012 database.
Adding Modify, Read, Write permissions to the folder containing the required file to the NETWORK SERVICE user seems to work for me.
I am trying to run a CakePHP Shell script through the Scheduled Task of Windows 2003 server and I'm finding that the task Could not start.
When I run it manually from the Command Prompt it works well:
C:\Inetpub\wwwroot\CakePHP\lib\Cake\Console\cake mail read
The Scheduled task Run field is exactly the same and the Start in is set to:
C:\Inetpub\wwwroot\tickets\app
The Run as field is set as the computer admin which has all permissions (not the ISS user)
Scheduled Task log shows this message when trying to execute it:
"Ticket Mail System.job" (cake) 13/12/2012 07:15:00 ** ERROR **
Unable to start task.
The specific error is:
0x80070005: Access is denied.
It seems it is a permissions problem.
I have tried to give over the lib/Cake/Consol/cake.bat file all permissions for both users, the IIS 6 user and the Internet Guest Account user, but still doesn't work.
Any idea which could be the cause?
It worked well over Windows 7 but it didn't on Window 2003 Server.
Finally, I tried it adding .bat after calling the Shell and it works.
I had to put this in the Run field:
C:\Inetpub\wwwroot\CakePHP\lib\Cake\Console\cake.bat mail read
It seems Windows 2003 needs the .bat at the end...
I found it at: http://www.geekyboy.com/archives/376
Thanks guys, this got my issue solved.
found that my ".bat" file instead had the extension ".CMD" which seemed to work fine up until now.
fixed it by renaming the file extension and changing the directory in the task scheduler.(because it still had the ".CMD" extension.