Issue with accessing network shares with the copy functions

[Michael Gebhardt]

Hi,

we're facing an issue with the following actions:
- Put File Or Folder In Remote Agent
- Copy Files or Folders

when the source and or destination path is a file share.

Somehow this happened from one day to the other, as yesterday deployments using those actions still succeeded.

The remote one throws this error:
(#1) Cannot put file on remote agent - cannot copy source [\\ournetworksharehiddenforsecurityreasons] to temporary directory [{installation directory}/files_temp/NimiActions/AgentFileTransfer_3c201395-2a9d-438c-b483-5858dff12366_1568177906964]

Which is kinda weird, cause why is it pointing to files_temp directory? is this a step during the move to the target host?

the normal copy one throws this:
Failed to complete copy of files/folders from source path [\\ournetworksharehiddenforsecurityreasons\x.dummy] to target path [\\ournetworksharehiddenforsecurityreasons\_tests\x.dummy].

Failed to resolve [\\ournetworksharehiddenforsecurityreasons] to its canonical path. Could be because of insufficient permissions, broken symbolic links or that the file doesn't exist.

When we use robocopy it works fine, so it looks like it's related to Java, as it's used by the CA-RA actions?
Anyone an idea?

thanks
Michael

p.s. the search function in this broadcom community is way worse than it was before, so no idea if a similar post already exists

[Michael Gebhardt]

another info: I recently upgraded our management and execution server to 6.6, but kept the agents on 6.5. the only change I did yesterday on CA-RA site was finishing the last execution server update, as this was delayed for a bit cause of issues on the server itself. but this execution server is not involved in the deployments that are currently failing

I currently don't know if our company IT did some changes, which might affect java

[Gregg Stewart]

Hi Michael,

In regards to the observation that it's sending data to files_temp - this is a step during the move to a target host. The files_temp directory is used anytime nimi is transferring files. But the reasoning behind why it couldn't copy the source to that location is not clear. Are you maybe setting the action to run as an impersonated user?

In regards to the "Copy Files or Folders" action, I don't have an overwhelming amount of experience with these type of copies. However, from the testing I had done (probably a few years ago) I recall permissions being an issue. From that time I remember first trying to use Mapped drives which failed. My understanding of why it failed was that it didn't recognize the mapped drives which made sense because, for me, I was:
a. using an agent that was set to start as the account: local system
b. even when I did try configuring the agent to use a user account - mapped drives you create while logged in as a user aren't globally available for that user. maybe there is something more accommodating related to setting up mapped drives via user profiles. this is not an area that I've ever played with (windows user profiles).
c. i think i'd tried doing it via configuring the action to use user impersonation. but if I recall correctly the results were similar to (b). 

After having tested mapped drives I had gone on to testing a UNC path - which is what I believe you're using above. If I recall correctly I needed to either:
a. configure the agent to start as a domain user that had access to that path; or
b. configure the action to use user impersonation - with a domain user that had access to that path. 

It is interesting that robocopy works. Based on that it sounds like you are already configuring the agent to start as a specific user or using user impersonation at the action level. Maybe it works if you use the IP address? Or maybe the backslashes need to be escaped by backslashes like so: \\\\ournetworksharehiddenforsecurityreasons\\_tests\\x.dummy

Kind regards,
Gregg

[Michael Gebhardt]

Hi Gregg,

thanks for the infos, sadly none of it helps.

I now tried even upgrading the agent to the latest version and using the IP instead of the DNS, as you suggested. Also tried escaping the backslashes.

Still getting the same error

The thing is also, it can't be a permission issue, as other actions work fine, it's only the copy that breaks, so CA-RA must use something here under the hood, that no longer works

:-(

regards
Michael

[Michael Gebhardt]

guess no one else is facing that?

bummer :-/