Before you sink a lot of time into it – read this: Internxt-cli WebDav Issue and reconsider choice of your storage provider. Nothing good will come out of this, you will waste time and then give up anyway. Don’t try to penny-pinch on the storage service: your backup is as reliable as underlying storage.
If you still want to try – continue reading.
So, here is the conundrum. The credentials in the json file are encrypted using machine-specific tools (keychain on macOS, DPAPI on windows, libsecret/gnome keyring on linux) that uses machine ID and user account among other things. It’s not portable. But the URL itself is not a factor in the encryption, so you can do switcharoo: configure the dummy connection to some local webdav server with the correct username and password, and then edit the URL in duplciacy.json.
Run the server (install uv if you dont’ have it):
uv run --with wsgidav,cheroot wsgidav --port=9980 --root=/tmp --auth=htdigest --user=foo:bar
and then add the webDAV connection in the Web UI to http://127.0.0.1:9980/ for user foo and password bar (use your actual username and password of the actual web service you are going to use.
The GUI will verify the connection and update duplicacy.json. Shut down duplicacy, and edit URL in the duplicacy.json to point to your actual web server.
Better approach woudl be to serve Interntx storage via rclone natively, and have duplicacy-web connect to it via, say, sftp.
Edit: glancing through that page further – they seem to support S3 (that’s how they configure themselves in rclone). Duplicacy supports S3 directly, depending on whether interntx exposes bucket style or path style you might want to use minio or s3 remote – see Duplicacy and wasabi stopped working out of the blue - #5 by gchen