Why I cannot connect/transfer using script, when I can using GUI (or vice versa)?

There are two common reasons why a script does not work, when a connectivity is otherwise possible:

• You run script from a different environment (under a different account/service; with a different configuration) than the GUI.
  See another FAQ: My script works fine when executed manually, but fails or hangs when run by Windows Scheduler, SSIS or other automation service. What am I doing wrong?1
• You have your session configured differently in the script and in the GUI.
  • Use a Generate Session URL/Code command to avoid common mistakes in manually typed URL’s or code; and to make sure all the settings from your GUI configuration is used in the script.
    A common problem is special characters in some part of the session URL (typically a password or a username).
  • Passphrase to an SSH private key is not a password, you need to specify it using -passphrase switch, not in a password part of the session URL.
  • With WebDAV and S3 protocols, it is possible that you do not have an access to the root folder (bucket list in S3). You may need to specify your WebDAV root or S3 bucket in the session URL. For example https://username@example.com/dav/ or s3://key@s3.amazonaws.com/bucket/. In .NET assembly, use SessionOptions.RootPath. Even if you have the code generated from a working WinSCP GUI session, it won’t include the root path, as the GUI cannot be aware of the root path restriction.

You can also enable a session logging both in the GUI (on Logging page of Preferences dialog) and the script (using a command-line parameter /log) and compare the logs to find out what is different. Use a command-line parameter /loglevel=* to enable a password logging and check if a correct password is used.

If you decide to seek a help, make sure you provide both complete logs, when describing your issue.

• More generic article on making WinSCP work in a new environment (operating system, machine, user account, network).
• Debugging transfer task running in Windows Scheduler, SSIS or other automation service.