SFTP-Out Delivery Fails With Failed to Open Local File While the Remote File Is Locked
The error Failed to deliver document '<FILENAME>.csv.pgp' to endpoint '<ENDPOINT>'. Reason: application=<APP_NAME> - SFTP-Out transport-id=SftpOutTransportSingleAuth failed to write file=... path=.... Reason: Failed to open local file. MSG_LOG_REF:<GUID>
What does "Failed to deliver document ' .csv.pgp' to endpoint '" mean in Workday Core Connector?
The delivery step could not write the output file to the SFTP server. The word local in the message describes the file as seen from the transport, so it usually points at the target directory or an existing file that cannot be replaced, not at anything inside Workday.
Quick fix
Clear or rename the existing file on the target path, or turn off Use Temp File on the SFTP transport, then rerun the delivery.
Permanent fix
Give every delivered file a unique name using a timestamp pattern the receiving server accepts, and agree with the receiving team that files are moved out of the landing directory once consumed. Where the partner cannot guarantee that, keep Use Temp File off and confirm overwrite rights on the exact path at build time.
Troubleshooting
- Read the word local as the remote side of the transfer, not the Workday side. That single misreading is what sends most people looking in the wrong place.
- Ask whether a file of the same name already exists in the target directory and whether the receiving system holds it open while processing. A locked file gives exactly this failure while a first run of the day succeeds.
- Confirm write and create permissions on the exact path, including any subdirectory, rather than on the login's home directory.
- Check the Use Temp File setting on the transport. Writing to a temporary name and renaming needs create plus rename rights, and a server that allows one but not the other fails only when that option is on.
- Look at the generated filename. Some SFTP servers reject colons or other punctuation produced by a timestamp pattern, and the resulting failure is reported the same way.
- If the same endpoint works from another integration, compare the two: a document retrieval step earlier in the run can leave a handle on the same path.
Was this helpful?