scp Permission denied

Please add -vv to ssh options, like so:

duplicity --ssh-options="-oIdentityFile=/etc/ssh/ssh_host_rsa_key -ovv" /root/mytest/...

Thank you for your reply!

root@myserver:~# duplicity --ssh-options="-oIdentityFile=/etc/ssh/ssh_host_rsa_key -ovv" /root/mytest/ scp://<email address hidden>//users/USERNAME/mytest/
Local and Remote metadata are synchronized, no sync needed.
Last full backup left a partial set, restarting.
Last full backup date: Sat Feb 27 11:56:19 2021
GnuPG passphrase for decryption:
Retype passphrase for decryption to confirm:
RESTART: The first volume failed to upload before termination.
         Restart is impossible...starting backup from beginning.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
GnuPG passphrase for decryption:
Retype passphrase for decryption to confirm:
No signatures found, switching to full backup.
Attempt 1 failed. BackendException: scp remote error: scp: '/users/USERNAME/mytest/': Permission denied

Sorry, I got that wrong. It should be:

duplicity -v9 --ssh-options="-oIdentityFile=/etc/ssh/ssh_host_rsa_key -oLogLevel=DEBUG3"

What I specified was for the ssh command line. Also include the -v9 above for duplicity itself.

No problem, here we go:

root@myserver:~# duplicity -v9 --ssh-options="-oIdentityFile=/etc/ssh/ssh_host_rsa_key -oLogLevel=DEBUG3" /root/mytest/ scp://<email address hidden>//users/USERNAME/mytest/
[...]
Backtrace of previous error: Traceback (innermost last):
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 369, in inner_retry
    return fn(self, *args)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 529, in put
    self.__do_put(source_path, remote_filename)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 515, in __do_put
    self.backend._put(source_path, remote_filename)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/ssh_paramiko_backend.py", line 304, in _put
    raise BackendException("scp remote error: %s" % chan.recv(-1))
 BackendException: scp remote error: scp: '/users/USERNAME/mytest/': Permission denied

Attempt 1 failed. BackendException: scp remote error: scp: '/users/USERNAME/mytest/': Permission denied
[...]

Complete output: https://pastebin.com/R4UuqwnA

I do not see the problem at this point. SSH is not the problem, no errors there. Duplicity is reporting 'Permission denied', but I don't see why.

One more thing to try, instead of 'scp:' use 'pexpect+scp:'. Keep all the debug options, just in case.

If that does not work, please upgrade to the current version of duplicity (0.8.18).  This will assure that any bugs fixed since your release are available and may fix your issue.

There are multiple options both stable and daily:
- Source - https://gitlab.com/duplicity/duplicity
- Stable tarball install - https://launchpad.net/duplicity/+download

- Stable duplicity PPA - https://code.launchpad.net/~duplicity-team/+archive/ubuntu/duplicity-release-git
- Daily duplicity PPA - https://code.launchpad.net/~duplicity-team/+archive/ubuntu/duplicity-develop-git

- Stable snap builds - “sudo snap install duplicity —classic"
- Latest snap builds - “sudo snap install duplicity —classic —edge"

- Stable pip3 builds - “sudo python3 -m pip install duplicity"
- Latest pip3 builds - “sudo python3 -m pip install --pre duplicity"

- Latest pip2 builds - "sudo python2 -m pip install --pre duplicity"

Note 1: UNINSTALL duplicity first if it was installed from a different source..  This is due to divergent install locations, especially between repository installs and the other forms.

Note 2: Launchpad PPAs contain builds for Bionic 18.04, Eoan 19.10, Focal 20.04, and Hirsute 20.10.  Xenial 16.04 works with Snap and Pip3 (Python 3) installs, but cannot be built under Launchpad PPAs at the moment.

Great, switching to pexpect+scp:// worked and the backup is transferring again.

Unfortunately, incremental backups and file listing doesn't work anymore. duplicity always says "Last full backup date: none", even after a full backup. The files are there on the remote backend.

list-current-files is maybe a little more helpful for debugging (see below). That is the output of "list-current-files" with the same parameters as the full backup just before:

Traceback (innermost last):
  File "/usr/bin/duplicity", line 1567, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1553, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1405, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1488, in do_backup
    list_current(col_stats)
  File "/usr/bin/duplicity", line 714, in list_current
    sig_chain = col_stats.get_signature_chain_at_time(time)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 998, in get_signature_chain_at_time
    raise CollectionsError("No signature chains found")
 CollectionsError: No signature chains found

Let the backup complete, then you will have the ability to list-current-files.

Sorry, wasn't clear: The backup has finished! It's just one small text file that completed when doing "duplicity full". But when I then do "list-current-files" (or "duplicity incremental") it says "Last full backup date: none" (for "duplicity incremental") and then quits with an error message because "incremental" was requested but no backup chains found. The output of "list-current-files" is above.

Sorry, all good: The problem was with a trailing slash on the remote path:

This one does do one full backup but does not allow incremental backups or "list-current-files" afterwards:
duplicity --ssh-options="-oIdentityFile=/etc/ssh/ssh_host_rsa_key" /root/mytest/ scp://<email address hidden>//users/USERNAME/mytest/

This one does and works as expected:
duplicity --ssh-options="-oIdentityFile=/etc/ssh/ssh_host_rsa_key" /root/mytest/ scp://<email address hidden>//users/USERNAME/mytest

Sorry if this is documented and I missed it. It worked in the older version of duplicity I used until now. Thank you for the help, really appreciate it.

hey Max,

any reason why you chose SCP over SFTP? i'm asking because the sftp is the more versatile and stable of these two see (a Note on Ssh Backends / Why use sftp instead of scp?)
http://duplicity.nongnu.org/vers8/duplicity.1.html#sect26

Strato Hidrive seems to offer both. regards.. ede

No reason except not knowing better. Never looked at SFTP in general and I liked the fact to be able to login via certificate instead of password. As that seems to be possible with SFTP too, I will switch to it!