Error backing up cluster: authentication failure

I want to change the Couchbase instance that does backups for other Couchbase clusters on my network.

The current version runs Couchbase 6.0.1 on Ubuntu 14.

The new instance is running Couchbase 7.0.1 on Debian 10.

The backup script works on the current version, but not the new version.

The error I get is:

Warning: --host is deprecated, use -c/--cluster
Backing up to '2022-07-25T15_25_27.696579637Z'
Deciding which key value data to transfer for bucket 'test'          0 items / 0B
[                                                                        ] 0.19%
Error backing up cluster: authentication failure

| Transfer
| --------
| Status | Avg Transfer Rate | Started At                      | Finished At                     | Duration |
| Failed | 0B/s              | Mon, 25 Jul 2022 15:25:27 +0000 | Mon, 25 Jul 2022 15:25:30 +0000 | 2.397s   |

I’m running this command:

/opt/couchbase/bin/cbbackupmgr backup --archive /backup/testing/20220725 --repo cb.testing.local --host couchbase://cb.testing.local --username ********* --password ********* --threads 1

The first thing I did was resolve the warning by changing --host to cluster, and got the same failure.

I then downgraded Couchbase to version 6.6.5 (I had to use a Docker container, because Debian 11 does not have Couchbase 6), and got the same failure.

I cannot downgrade any further, it seems, because earlier versions have the log4j vulnerability.

Why does the same script with the same command and the same parameters fail on a different machine?

Thank you.

Additional Note: On neither machine is the Couchbase installation setup – there is no active cluster. The service is running but it’s really just installed to have access to cbbackupmgr.

Since the error is authentication failure, is it possible that the password has special characters that could be interacting with the shell? (The password should be in single or double quotes to prevent interaction with the shell if it has special characters.)
Also, can check the backup log inside logs directory in the archive directory (e.g. /backup/testing/20220725/logs) to see if there are additional info.