HTTP 409 errors Jottacloud (crypt)

What is the problem you are having with rclone?

Testing out Jottacloud as a replacement for Backblaze B2 (secondary cloud backup) as it could be cheaper for my needs as well as add GUI backup option. I like the idea of having data with a European company in Europe too.

Am using free 5GB tier so limited testing. I have created a remote, and a crypt version, and successfully connected and copied data via the crypt. I can also mount it on Mac via the adapted shortcuts I use for my other rclone remotes. Speeds are good.

But, of the single 4.5GB folder of photos I can test, I get some errors uploading:

2026/05/13 10:41:16 ERROR : photo.jpg: Failed to copy: HTTP error 409 (409 Conflict) returned body: "{\"message\":\"\"}\n"

They resolve and all data gets copied but it’s unnerving.

I have 3-4TB to shift across (using rclone on a VPS) so I would like to know its reliable and if I can safely ignore (or ideally remove) these errors!

Run the command 'rclone version' and share the full output of the command.

rclone v1.74.1

  • os/version: darwin 26.4.1 (64 bit)
  • os/kernel: 25.4.0 (x86_64)
  • os/type: darwin
  • os/arch: amd64
  • go/version: go1.26.3
  • go/linking: dynamic
  • go/tags: cmount

Which cloud storage system are you using? (eg Google Drive)

Jottacloud (free 5GB)

The command you were trying to run (eg rclone copy /tmp remote:tmp)

I have also tried without any options, no difference.

rclone -vP --fast-list  --checksum --transfers=12 copy /Users/XX/Dropbox/Photos/LR_Exports/original-res jot_crypt:/test-photos-crypt

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

Paste config here:

[jot]
type = jottacloud
configVersion = 1
client_id = XXX
client_secret = 
tokenURL = https://id.jottacloud.com/auth/realms/jottacloud/protocol/openid-connect/token
token = XXX
device = 
mountpoint = 

[jot_crypt]
type = crypt
remote = jot:/rclone_crypt/
password = XXX
password2 = XXX

A log from the command that you were trying to run with the -vv flag

Paste  log here:

/Users/XX/ % rclone -vv --fast-list  --checksum --transfers=12 copy /Users/XX/Dropbox/Photos/LR_Exports/original-res/ jot_crypt:/test-photos-crypt 
2026/05/13 11:27:03 DEBUG : rclone: Version "v1.74.1" starting with parameters ["rclone" "-vv" "--fast-list" "--checksum" "--transfers=12" "copy" "/Users/XX/Dropbox/Photos/LR_Exports/original-res/" "jot_crypt:/test-photos-crypt"]
2026/05/13 11:27:03 DEBUG : Creating backend with remote "/Users/XX/Dropbox/Photos/LR_Exports/original-res/"
2026/05/13 11:27:03 DEBUG : Using config file from "/Users/XX/.rclone.conf"
2026/05/13 11:27:03 DEBUG : Creating backend with remote "jot_crypt:/test-photos-crypt"
2026/05/13 11:27:03 DEBUG : Creating backend with remote "jot:/rclone_crypt/am1855ludrjlgtei4631m6ojtcb7ask8pno3qqdopt2ou20mut6g"
2026/05/13 11:27:03 DEBUG : fs cache: renaming cache item "jot:/rclone_crypt/am1855ludrjlgtei4631m6ojtcb7ask8pno3qqdopt2ou20mut6g" to be canonical "jot:rclone_crypt/am1855ludrjlgtei4631m6ojtcb7ask8pno3qqdopt2ou20mut6g"
2026/05/13 11:27:03 DEBUG : fs cache: switching user supplied name "jot:/rclone_crypt/am1855ludrjlgtei4631m6ojtcb7ask8pno3qqdopt2ou20mut6g" for canonical name "jot:rclone_crypt/am1855ludrjlgtei4631m6ojtcb7ask8pno3qqdopt2ou20mut6g"
2026/05/13 11:27:03 DEBUG : 10_10_3738.jpg: Need to transfer - File not found at Destination
2026/05/13 11:27:03 DEBUG : 10_10_3745.jpg: Need to transfer - File not found at Destination
2026/05/13 11:27:03 DEBUG : 10_10_3749.jpg: Need to transfer - File not found at Destination
2026/05/13 11:27:03 DEBUG : 10_10_3751.jpg: Need to transfer - File not found at Destination
2026/05/13 11:27:03 DEBUG : 10_10_3756.jpg: Need to transfer - File not found at Destination
.
.
.
2026/05/13 11:27:09 DEBUG : 10_11_3841.jpg: Computing md5 hash of encrypted source
2026/05/13 11:27:10 ERROR : 10_11_3841.jpg: Failed to copy: HTTP error 409 (409 Conflict) returned body: "{\"message\":\"\"}\n"
2026/05/13 11:27:10 DEBUG : 10_11_3844.jpg: Computing md5 hash of encrypted source
2026/05/13 11:27:10 DEBUG : 10_11_3814.jpg: md5 = 6c07307e97e36e7a27ef9d6330ac762f OK
2026/05/13 11:27:10 DEBUG : 10_11_3814.jpg: size = 8125034 OK
2026/05/13 11:27:10 INFO  : 10_11_3814.jpg: Copied (new)
.
.
.
2026/05/13 11:27:59 DEBUG : Encrypted drive 'jot_crypt:/test-photos-crypt': Waiting for transfers to finish
2026/05/13 11:28:00 DEBUG : 10_20_4383.jpg: md5 = d92351debfa720d907698bb57948b03e OK
2026/05/13 11:28:00 DEBUG : 10_20_4383.jpg: size = 17765447 OK
2026/05/13 11:28:00 INFO  : 10_20_4383.jpg: Copied (new)
2026/05/13 11:28:00 ERROR : Attempt 3/3 succeeded
2026/05/13 11:28:00 INFO  : 
Transferred:   	    4.347 GiB / 4.347 GiB, 100%, 83.357 MiB/s, ETA 0s
Checks:               601 / 601, 100%, Listed 1516
Transferred:          305 / 305, 100%
Elapsed time:        56.3s

(just to note, I just tried their Mac Application and was so disappointed- it was so basic that it wouldn’t be that useful for me, so I'd really be relying on rsync - or trying their CLI I guess)

maybe test a simpler setup

change remote = jot:/rclone_crypt/ to remote = jot:rclone_crypt

rclone -vvP copy /Users/XX/Dropbox/Photos/LR_Exports/original-res jot_crypt:test-photos-crypt

Forgive me but what would that achieve?

All my backup jobs to other remotes point to similar paths so I’m not sure what this change would reveal? ultimately the backup job will be much more complex with thousands of folders,

Thank you.

Forgive me but what would that achieve?

I assume it was just to rule out any inconsistencies with the path, there are some backends where leading slash changes the meaning.

Do you have anything in the trash of your Jotta account? There was some issues with that at some point (e.g. uploading a new file to the same path as one already in trash), but should not be the case now - so another one of those; just to rule out, you could try to reproduce without anything in trash.

No, was a brand new account on the first run.

Each time, to repeat the test (4 times in total) I had to delete the folder and empty the trash on Jotta to free up enough space (seemingly the Trash folder still counts as usage).
Similar or the same result each time - ‘a bunch’ of files gave this error but resolved. I didn’t do it scientifically enough to check if it was the same files, it was around 3-5 errors out of about 600 files.

I may just try copying to the unencrypted and see if there’s any difference (not that I would use that ultimately). If it feels like its going ton be a bit iffy I’ll just stick with B2, at least it works and the Jottacloud Mac gui doesn’t add the benefit I thought it would.

I’ll try the / removal on the dest for good measure, all my rclone commands are written like that though and they always end up where I expect…. in fact I assumed it was just standard unix type paths.

removing the slash and copying to jot:rclone_crypt made no difference.

nor did writing to the unencrypted jot remote. same situation, a few errors, this time looks like one wasn’t resolved?

2026/05/14 14:28:15 ERROR : Attempt 3/3 failed with 1 errors and: HTTP error 409 (409 Conflict) returned body: "{\"message\":\"\"}\n"
2026/05/14 14:28:15 INFO  : 
Transferred:   	    4.335 GiB / 4.335 GiB, 100%, 75.923 MiB/s, ETA 0s
Errors:                 1 (retrying may help)
Checks:               593 / 593, 100%, Listed 1508
Transferred:          304 / 304, 100%
Elapsed time:        59.1s

2026/05/14 14:28:15 DEBUG : 131 go routines active
2026/05/14 14:28:15 NOTICE: Failed to copy: HTTP error 409 (409 Conflict) returned body: "{\"message\":\"\"}\n"

trying the same folder to a dropbox_crypt, all went through OK, albeit far slower…

Transferred:   	    4.341 GiB / 4.341 GiB, 100%, 31.082 MiB/s, ETA 0s
Checks:                 0 / 0, -, Listed 305
Transferred:          305 / 305, 100%
Elapsed time:       2m6.2s

2026/05/14 14:34:34 DEBUG : 8 go routines active
2026/05/14 14:34:34 INFO  : Dropbox root '_backups/rclone/Crypt/233.NyMN-JBINIM-wLSJN': Committing uploads - please wait...

I’ll reach out to Jottacloud although I hear they generally just say rclone isn’t supported, and use the CLI, which I wouldn't mind if I could encrypt.

for a deeper look, try --dump flags, such a --dump=bodies
and to keep the debug log smaller, use --retries=1

so far, not able to reproduce your issue

[jottacloud]
type = jottacloud
configVersion = 1
client_id = XXX
client_secret =
tokenURL = https://id.jottacloud.com/auth/realms/jottacloud/protocol/openid-connect/token
token = XXX
device =
mountpoint =
rclone copy d:\data\file.ext jottacloud:zork -vv
DEBUG : rclone: Version "v1.74.1" starting with parameters ["rclone" "copy" "d:\\data\\file.ext" "jottacloud:zork" "-vv"]
DEBUG : Creating backend with remote "d:\\data\\file.ext"
DEBUG : Using config file from "d:\\data\\rclone\\rclone.conf"
DEBUG : fs cache: renaming child cache item "d:\\data\\file.ext" to be canonical for parent "//?/d:/data"
DEBUG : Creating backend with remote "jottacloud:zork"
DEBUG : file.ext: Need to transfer - File not found at Destination
DEBUG : file.ext: size = 1 OK
DEBUG : file.ext: md5 = c4ca4238a0b923820dcc509a6f75849b OK
INFO  : file.ext: Copied (new)

Thanks for trying. How many files was this? Wonder if it’s a speed thing as I do have quite a fast 1Gbps connection, and it runs quote a bit faster (>2x) to Jottacloud than dropbox. Shame I can’t try on a bigger number of files without paying to subscribe.

Since rclone isn’t officially supported, can anyone expand on what could possibly cause a 409 HTTP error, to help my asking their technical support?

I asked chatGPT, its final suggestion was:

7. Backend bugs or API edge cases

The Jottacloud backend in rclone has historically had some 409-related issues around:

modified timestamps

uploads > several GB

dedupe/versioning

Update to latest rclone first:

Note: I also took its earlier suggestion of using --transfers 1 --checkers 1 incas it was parallel stuff but apart from being slower the same errors popped up.

Gave up with this really. Can’t work out the Http errors and no more time to experiment.

If the Mac GUI and/or the CLI was good I would probably have persisted, but so far just can’t really get a handle on what they were thinking. For example, backing up a folder buried down in a tree via the CLI (or the GUI) just dumps it a the root of the remote.

So:

SourceMachine:/<full_path_to_folder>/A_folder_to_backup

becomes:

CloudLabelofSourceMachine:/A_folder_to_backup

And then it’s not encrypted either. Doesn’t make any sense to me, would just leave a mess at the cloud end. Either I’m missing something or it’s juts not designed for me. The search continues, seems like its hard to find an EU cloud provider that looks like it might be around for a while, is stable and feature rich, affordable and works well with a Mac via a GUI (preferred) or at least rclone compatible.

Shame really, I had high hopes for it!

i have been using hetzner storagebox for 6+ years. works good, priced good.

in addition, i rent the cheapest cloud vm in the same datacenter.
on that i run rclone, which can access storagebox as local storage.
the whole thing runs over tailscale.

Thanks - I did attempt to try that one but drew the line at uploading my passport to a cloud provider…… and prefer to find something at least offering a gui based service so other family members might use it rather than iCloud/dropbox.

yeah, that is terrible but understanable.
i never had that issue as i pay via paypal


as i mentioned, i rent a cheap vm, so i could run whatever software i want, such as nextcloud, jellyin, etc

or skip the vm and use hetzner storage share which uses nextcloud and get all the other benefits such as zfs backups and snapshots.

Wasn’t aware of the PayPal option getting around it. But the whole thing kind of put me off as it seemed counter to data security from my perspective and support were glacially slow (days) for each contact and not very helpful. Appreciate others may be less concerned. Decided not to persue and don’t really want to manage multiple things - use a vm now and again to copy stuff between cloud storages but it’s a bit of a faff and more than I want to deal with long term I want a less ‘techy’ solution where the cloud provider does most of the tech for me that’s what lured me to jotta.

I’ll probably stick with B2 for now backing up vital stuff and the usual mainstream ones generally. B2 cost is starting to mount as I store more though and the web gui isn’t exactly refined, but it’s been pretty bombproof. I considered their non B2 service but it all seemed pretty fussy - like the ‘plug your external drives in every 30 days or the data gets destroyed’ type stuff. I guess they’re all trying to offer you unlimited but not actually give you unlimited since that’s probably not viable so they all find workarounds to get out of it - now I’m writing this it feels a bit like insurance companies.

for older backups, that i never expect to use, such as large veeam backups,
i move that to aws s3 deep glacier $1.00/TiB/month

I looked at AWS but am doing my best to boycot Aamzon. Also as far as I could tell I’d need a new mortgage to download/restore if I ever needed to….

I sound like a difficult customer I know…..

Currently checking out Internxt, especially as its also listed above in the ad!

Urgh. Ok scrap internxt - do t think I’ve ever seen that many p****d off customers spread over the internet for any company. I give up. I might just get a new NAS!