I have batch files, its copy some files from network to local disk. When try to run it from a windows service I get an error like "Access Denied".
I already try run windows service as LocalSystem , LocalService and NetworkService. All these types get same error.
Have any idea ?
Thanks
NetworkService is the only one that is going to include network credentials here, and that will be the local machine's identity. Does the machine account have access to the share? If this isn't correct, you'll need to run the service as a dedicated, specific user account.
What version of windows is this ? And have you checked the effective ACL settings of the shared files/folders ?
Try changing the ACL on the shared resource to allow everyone access...
If that works you need to give DOMAIN\networkservice the correct permissions. In this case both machines would need to be in the correct domain.
Related
I am trying to get some automatic deployments up and running using TFS 15 (on-premise). I have a powershell script on the deployment target to call.
The deployments starts fine by downloading the artifact. But when the agent runs the script it wants to create a folder C:\Windows\DtlDownloads (thats not part of my script but part of preparing things for TFS I guess). That fails:
##[debug]System.AggregateException: Failed to install 'VisualStudioRemoteDeployer20597940-38b2-4ba8-9a4d-fcc894308730' from service executable path VisualStudioRemoteDeployer.exe . Consult the logs below:
Access to the path 'DtlDownloads' is denied.
CategoryInfo :PermissionDenied: (C:\Windows\DtlDownloads:String) [New-Item], UnauthorizedAccessException
FullyQualifiedErrorId :CreateDirectoryUnauthorizedAccessError,Microsoft.PowerShell.Commands.NewItemCommand
The user used to logon is a server-local user named deploy who is also a local administrator on that machine. I also checked the effective access for that user on the windows folder and it should be able to create directories.
Something similar happens with the copy step. Robocopy signals two errors:
2017/03/16 08:57:21 ERROR 5 (0x00000005) Getting File System Type of Destination \\server.domain.com\c$\abc\def\
Access is denied.
and
2017/03/16 08:57:21 ERROR 5 (0x00000005) Creating Destination Directory \\server.domain.com\c$\abc\def\
Access is denied.
The second is a bit unexpected as the folder def already exists but I guess it is a follow up because getting the type failed beforehand.
The user itself must have been recognized because I get different errors when using invalid credentials. I have enabled WinRM using Enable-PSRemoting and ConfigureWinRM.ps1 from WinRM-Http-Https-Without-Makecert.
What could still restrict the permissions?
Update: Using a domain user instead of a local one of that server solves the issue. But I do not understand why. Can someone explain or even provide information how to make it work with a local user?
The username of either a domain or a local administrative account on
the target host(s).
Formats such as username, domain\username, machine-name\username, and .\username are supported.
UPN formats such as username#domain.com and built-in system accounts such as NT Authority\System are not supported.
Source Link
Both the domain account and local admin should be work. Please double check your format and give a try with another format.
One problem could be if that you have the agent as a service, that service has not the proper privileges, like being on Network Account. Try to change that to the user account which has administrative privileges.
Running "winrm quickconfig" fixed this problem for me
winrm quickconfig
https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management
I'm not sure if this is proper place for such question (maybe should be placed on SuperUser?), but I'll try.
I have one C# console application and one Windows service. Both does the same, but console app was created before and is kept for backward compatibility. Each of these is running WCF service, whose methods operates on files in C:\ProgramData\MyApp. Console app is run as limited user (non-admin), Windows service runs as NT AUTHORITY\NETWORK SERVICE. When app creates some dirs/files, service cannot delete it and vice versa.
I would like to have it secured. My question is: should I grant full permissions on C:\ProgramData\MyApp to NETWORK SERVICE and current user? Or should I create dedicated user for running service/app?
Assuming your application does not set explicit security permission on newly created files, granting Network Service account Delete permissions on the folder would solve your immediate problem.
This command will do the work:
icacls c:\ProgramData\MyApp /t /grant "NETWORK SERVICE":(OI)(CI)(IO)D
Repeat the same for your other user service account.
I'm using the ArtifactDeployer plugin to deploy the build job artifacts to a remote location (Windows share SMB).
However Jenkins never manages to succeed. Throwing errors like:
[ArtifactDeployer] - Starting deployment from the post-action ...
[ArtifactDeployer] - [ERROR] - Failed to deploy. Can't create the directory ... Build step
[ArtifactDeployer] - Deploy artifacts from workspace to remote directories' changed build result to FAILURE
Local deployment works fine.
The Jenkins machine OS is Windows 7 32-bit Prof.
Jenkins is running as a service using a local system account.
I tried using another account, my user account but the service failed to start (Windows error 1069: the service did not start due to a logon failure).
The network service account did run but than Jenkins throws errors it can't access the .NET framework.
When manually trying the remote copy, this works fine. I can create directories and write to it. On the same machine of course.
I tried two different remote reference in Jenkins:
1) \\targetdirectory
2) I:\ - by mapping a drive letter to the remote dir in windows
No success...
Any tips or suggestions? Thanks!
Update 15/02/2012:
Still no solution or workaround for this issue.
It's not only the plugin, I hit also this issue using "Execute Windows batch command".
I found a bug report that I want to share.
Solution
I found a solution. You have to grant access persmission to the computer in a domain instead of the user of that machine. Seems very logic if you look back to it.
A 2nd solution is to run the service using a domain user account. Above I made a mistake by using the local user .\user in stead of DOMAIN\user.
If you don't have a domain, the following will work for sure. This should work even if you have a domain.
Background Info:
You need your mapped drive to be mapped for the same account that the service is using AND be available at the right time. Normally mapped drives are mapped only for the logged in user, at the time that they log in. Service user contexts don't get "logged in" per se -- for example, if I map a drive as MyUser and the service runs as MyUser, the drive won't be available until I actually log in by typing in my password. However, we can use a script to map the drive at startup (instead of login) for a particular user. Jenkins normally runs as Local System Account, so if you don't want to change that, you'll need to run the script below as the SYSTEM user. You can instead create a specific user for Jenkins to run as, if you don't want to grant this mapped drive to all services/processes that run as SYSTEM, and run both the service and the script below as that user (this is probably more secure).
Solution Steps:
In ArtifactDeployer you want to deploy to a mapped network drive. In my case this is S:.
There is no special setup for permissions on the remote share. (In my case, a Windows Server 2008 share with a username and password that is used for mapping the drive.)
Write a batch file MapDrives.bat in a place that your chosen user (default: SYSTEM) has access to, with the following in it:
net use S: "\\server_name\share_name" /persistent:yes password_here /USER:username_here
Note that I am mapping to S: in that line.
Via Task Scheduler, create a task that runs as the same user as the service (default: SYSTEM), triggers At Startup, and as it's action, runs the batch file MapDrives.bat.
Reboot and it should work!
Citations:
After diving through many pages and many tests, ultimately, the best suggestions were found here, and led me to the above solution.
https://stackoverflow.com/a/4763324/150794
Make sure your 'local system account' has access rights to the remote directory (including write access). Then use the notation
\\targetdirectory
Mapping drive letters to remote directories only applies to the user account you are currently working with. The drive letter mapping will not be available to any other account.
I have a Windows Service created in .NET 4.
I need to access a file from antoher server and I get an exception:
"UnauthorizedAccessException was caught" - "Access to the path '(path)' is denied."
If I make a new Windows Forms application which accessed that file, it works. The Windows Service runs as Local System.
Apparently your machine account does not have permissions to access remote file share. You have to grant rights to the machine account <DOMAIN>\<machine_name>$ on both file share level as well as file system level. For share permissions use fsmgmt.msc, for file system you can do it using cacls command.
Alternative solution is to impersonate a valid user account that already has permission to this directory.
I created one service which is running in one server and I need to copy directory from another server to directory in this server through this service. The service is failed when finding directory specified in another server. Like If DirectoryExists("\\ServerName\DirectoryName"). It is not working even, I set up the service with Network Authority.
Please give solution for this. It will be helpful.
Mallik.
A possible explanation is that the service runs as a user that does not have read rights to the other server's volumes. Authenticating with NETWORKSERVICE does not help you. That's just a user that has access to TCP etc.
What you need to do is to run your service as a user which has read access to the other server's volumes. As a test try your personal login, but in the longer run you may wish to use a dedicated user just for this task.