SFTP does not work in RoboHelp 2020 Update 5

[Sylvio5FB7]

Publishing to SFTP does not work with RoboHelp 2020 update 5.

SFTP is enabled - and working - on my Ubuntu server. I can connect to it and upload files using WinSCP (a simple GUI SFTP client for Windows).

However, I can't upload files from RoboHelp directly, which is annoying.

One thing I noticed is that when I configure the SFTP server's address in the publish profile, RoboHelp insists on adding "https://" in front of the IP address, and will not let you save with just the IP address.

As it turns out, RoboHelp then tries to connect to "https://192.168.xxx.xxx", which will never work, since adding "https://" in front of the address makes it incorrect... This theory seems to be supported by the error message found in the publish log:

Error: connect: client-socket error. Address lookup failed for host https://192.168.---.--- after 1 attempt

To validate this theory, I manually edited the "Publish_profiles.json" file found in C:\Users\%username%\AppData\Roaming\Adobe\RoboHelp\2020. This got rid of the error message stated above, so I think I have identified a bug, but this does not resolve the issue yet...

Now, I no longer get the error message, but my files won't make it to the SFTP server. Now, the log says that everything was published correctly, but when I look on the server, the destination folder is empty.

Looking at the "Publish_profiles.json" file further, I noticed that the path I entered:

/var/www/test/

was modified by Robohelp to:

/var/www/test

(the forward-slash (/) was removed by robohelp while saving the publish profile.)

Manually adding the missing forward slash directly in Publish_profiles.json and re-launching RoboHelp resolved the issue.

So, after all this, we have 2 issues:

1- RoboHelp forcibly adds "https://" in front of the SFTP server address, which causes a connection error.

2- RoboHelp removes the trailing forward-slash at the end of the path, which causes files not to be uploaded to the SFTP server. (I don't know if this is an issue for other SFTP servers, but I confirm that this is problematic for my ubuntu-based SFTP server.)

[Amebr]

I think this is the first query regarding SFTP I've seen. I think your best bet might be to contact Robohelp support. See the following page for support contact options:
https://helpx.adobe.com/contact/enterprise-support.other.html#robohelp

[Peter Grainge]

To be correct, it is not working for you. I have been using it to publish but where I had been using nnn.nnn etc I had to change to the server name.

The link Amber gave you was what we had been using but we have just learned that emailing tcssup@adobe.com to reach a team dedicated to Technical Communication Suite products including RoboHelp might be better.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[Sylvio5FB7]

Hi Peter!

To be fair, the SFTP publishing feature actually works after the Publish_profiles.json file has been edited to correct the errors introduced by RoboHelp. So, you are correct in mentioning that this is not an issue with the publishing engine by itself. It is actually an issue with the user interface, where the various parameters are configured.

I'm currently participating in the Beta program, so I submitted a detailed bug report there. The actual issue is that RoboHelp attempts to "correct" the IP address by adding "https://" in front of it, which it shouldn't. It also attempts to "correct" the server path by removing the trailing slash, which is required, at least when publishing to an Ubuntu based web server over SFTP. It may be different for other Linux distros or other SFTP servers, but I can't speak to that. All I can say is that if that trailing slash is omitted when publishing to an Ubuntu-based server, your files will not be uploaded.

Long story short, RoboHelp shouldn't attempt to "correct" the server's IP address or hostname, neither should it attempt to correct the server path. I my case here, this only introduced errors. Fortunately, this can be worked around by manually editing the Publish_profiles.json file.