"skipping undecryptable file name" notices

rcloningnemo · February 28, 2026, 5:57pm

What is the problem you are having with rclone?

I’m not precisely sure with which version of rclone this started happening, but after updating recently, I have started seeing the following notice when running “rclone sync” with two of my encrypted remote folders -

NOTICE: ꏺ沣庘媘䃨蓪㹓鶗❈㕟肩ҿ䐷莈䵷嘑厳蜼㝮燉磕葜熞玽ᆕ愬聇谈礆䂡㇞倝俵髼ɟ/㿄䈸㤦槚蝄⡘䘺欹嶃▸萰固ߊ哙ᣓ䥼禰痰㯔䅀㛞晪㯔伔闕ꂟ (Conflict ): Skipping undecryptable file name: illegal base32768 data at input byte 52

The sync still seems to complete OK, but if there’s a problem with my files, I’d like to fix it!

I use several other rclone commands similar to the below which do not produce the notice, and differ only in the path/folder that I am trying to synchronise (but these directories are all on the same, encrypted remote). This makes me think that either -

(a) there’s a couple of files on my system which are causing trouble somehow, but I do not know how to (locally) map/decode the base32768-encoded names to pinpoint them, or

(b) maybe there’s something in rclone’s name encryption routine which “doesn’t like” certain filenames (since I only have this problem with (I think) two files out of tens of thousands)…

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

rclone v1.73.1
- os/version: debian 11.11 (64 bit)
- os/kernel: 4.4.59+ (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.25.7
- go/linking: static
- go/tags: none

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

jottacloud

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

rclone sync --progress --jottacloud-no-versions --jottacloud-hard-delete --low-level-retries 30 --delete-before --transfers 4 --order-by modtime,ascending --check-first --exclude-from /root/rclone_exclude "/path/to/files" "jottacloud_encrypted:Diskstation/path/to/files"

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

[jottacloud_encrypted]
type = crypt
remote = jottacloud_unencrypted:backups
filename_encoding = base32768
password = XXX
password2 = XXX

[jottacloud_unencrypted]
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 =

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

2026/02/28 17:20:46 DEBUG : rclone: Version "v1.73.1" starting with parameters ["rclone" "sync" "--progress" "--jottacloud-no-versions" "--jottacloud-hard-delete" "--low-level-retries" "30" "--delete-before" "--transfers" "4" "--order-by" "modtime,ascending" "--check-first" "--exclude-from" "/root/rclone_exclude" "/path/to/files" "jottacloud_encrypted:Diskstation/path/to/files" "-vv" "--log-file" "t.txt"]
2026/02/28 17:20:46 DEBUG : Creating backend with remote "/path/to/files"
2026/02/28 17:20:46 DEBUG : Using config file from "/home/admin/.config/rclone/rclone.conf"
2026/02/28 17:20:46 DEBUG : Creating backend with remote "jottacloud_encrypted:Diskstation/path/to/files"
2026/02/28 17:20:46 DEBUG : Creating backend with remote "jottacloud_unencrypted:backups/夦⛼妇觜⚴痋歄泀㚿/酏䑝䤻榊瀱䆥淶䤒柟/ꏺ沣庘媘䃨蓪㹓鶗❈㕟肩ҿ䐷莈䵷嘑厳蜼㝮燉磕葜熞玽ᆕ愬聇谈礆䂡㇞倝俵髼ɟ"
2026/02/28 17:20:46 DEBUG : jottacloud_unencrypted: detected overridden config - adding "{Z4Gpd}" suffix to name
2026/02/28 17:20:47 DEBUG : fs cache: renaming cache item "jottacloud_unencrypted:backups/夦⛼妇觜⚴痋歄泀㚿/酏䑝䤻榊瀱䆥淶䤒柟/ꏺ沣庘媘䃨蓪㹓鶗❈㕟肩ҿ䐷莈䵷嘑厳蜼㝮燉磕葜熞玽ᆕ愬聇谈礆䂡㇞倝俵髼ɟ" to be canonical "jottacloud_unencrypted{Z4Gpd}:backups/夦⛼妇觜⚴痋歄泀㚿/酏䑝䤻榊瀱䆥淶䤒柟/ꏺ沣庘媘䃨蓪㹓鶗❈㕟肩ҿ䐷莈䵷嘑厳蜼㝮燉磕葜熞玽ᆕ愬聇谈礆䂡㇞倝俵髼ɟ"
2026/02/28 17:20:47 DEBUG : fs cache: switching user supplied name "jottacloud_unencrypted:backups/夦⛼妇觜⚴痋歄泀㚿/酏䑝䤻榊瀱䆥淶䤒柟/ꏺ沣庘媘䃨蓪㹓鶗❈㕟肩ҿ䐷莈䵷嘑厳蜼㝮燉磕葜熞玽ᆕ愬聇谈礆䂡㇞倝俵髼ɟ" for canonical name "jottacloud_unencrypted{Z4Gpd}:backups/夦⛼妇觜⚴痋歄泀㚿/酏䑝䤻榊瀱䆥淶䤒柟/ꏺ沣庘媘䃨蓪㹓鶗❈㕟肩ҿ䐷莈䵷嘑厳蜼㝮燉磕葜熞玽ᆕ愬聇谈礆䂡㇞倝俵髼ɟ"
2026/02/28 17:20:47 INFO  : Encrypted drive 'jottacloud_encrypted:Diskstation/path/to/files': Running all checks before starting transfers
2026/02/28 17:20:47 DEBUG : Waiting for deletions to finish
2026/02/28 17:20:47 DEBUG : @eaDir: Excluded
2026/02/28 17:20:47 NOTICE: 㿄䈸㤦槚蝄⡘䘺欹嶃▸萰固ߊ哙ᣓ䥼禰痰㯔䅀㛞晪㯔伔闕ꂟ (Conflict ): Skipping undecryptable file name: illegal base32768 data at input byte 52
2026/02/28 17:20:47 DEBUG : Encrypted drive 'jottacloud_encrypted:Diskstation/path/to/files': Waiting for checks to finish
2026/02/28 17:20:47 INFO  : Encrypted drive 'jottacloud_encrypted:Diskstation/path/to/files': Checks finished, now starting transfers
2026/02/28 17:20:47 DEBUG : Encrypted drive 'jottacloud_encrypted:Diskstation/path/to/files': Waiting for transfers to finish
2026/02/28 17:20:47 INFO  : Encrypted drive 'jottacloud_encrypted:Diskstation/path/to/files': Running all checks before starting transfers
2026/02/28 17:20:47 DEBUG : @eaDir: Excluded
2026/02/28 17:20:47 NOTICE: 㿄䈸㤦槚蝄⡘䘺欹嶃▸萰固ߊ哙ᣓ䥼禰痰㯔䅀㛞晪㯔伔闕ꂟ (Conflict ): Skipping undecryptable file name: illegal base32768 data at input byte 52
2026/02/28 17:20:47 DEBUG : Filename.exe: size = 2871550 OK
2026/02/28 17:20:47 DEBUG : Filename.exe: Size and modification time the same (differ by 0s, within tolerance 1s)
2026/02/28 17:20:47 DEBUG : Filename.exe: Unchanged skipping
...
<Many similar entries like the previous 3 lines>
...
2026/02/28 17:20:47 INFO  : Encrypted drive 'jottacloud_encrypted:Diskstation/path/to/files': Checks finished, now starting transfers
2026/02/28 17:20:47 DEBUG : Encrypted drive 'jottacloud_encrypted:Diskstation/path/to/files': Waiting for transfers to finish
2026/02/28 17:20:47 INFO  : There was nothing to transfer
2026/02/28 17:20:47 INFO  : 
Transferred:   	          0 B / 0 B, -, 0 B/s, ETA -
Checks:               289 / 289, 100%, Listed 1158
Elapsed time:         0.5s

2026/02/28 17:20:47 DEBUG : 9 go routines active

asdffdsa · February 28, 2026, 6:04pm

welcome to the forum,

can you please post the output of
rclone test info --check-base32768 jottacloud_unencrypted:backups

rcloningnemo · February 28, 2026, 6:21pm

Sure -

2026/02/28 18:19:31 NOTICE: jottacloud root 'backups/rclone-test-info-yeduzug7/test-base32768': 0 differences found
2026/02/28 18:19:31 NOTICE: jottacloud root 'backups/rclone-test-info-yeduzug7/test-base32768': 1028 matching files
// jottacloud_unencrypted
base32768isOK = true // make sure maxFileLength for 2 byte unicode chars is the same as for 1 byte characters

Does that give any clues?

asdffdsa · February 28, 2026, 6:33pm

actually, i should have asked you to run
rclone test info --check-base32768 --check-length jottacloud_unencrypted:backups:

rclone test info --check-base32768 --check-length onedrivevb:
2026/02/28 13:32:03 NOTICE: OneDrive root 'rclone-test-info-wavibaz0/test-base32768': 0 differences found
2026/02/28 13:32:03 NOTICE: OneDrive root 'rclone-test-info-wavibaz0/test-base32768': 1028 matching files
// onedrivevb
maxFileLength = 337 // for 1 byte unicode characters
maxFileLength = 337 // for 2 byte unicode characters
maxFileLength = 337 // for 3 byte unicode characters
maxFileLength = 168 // for 4 byte unicode characters
base32768isOK = true // make sure maxFileLength for 2 byte unicode chars is the same as for 1 byte characters

rcloningnemo · February 28, 2026, 6:58pm

No problem, happy to run that one, too

Result -

2026/02/28 18:57:22 NOTICE: jottacloud root 'backups:/rclone-test-info-ruwugef4/test-base32768': 0 differences found
2026/02/28 18:57:22 NOTICE: jottacloud root 'backups:/rclone-test-info-ruwugef4/test-base32768': 1028 matching files
// jottacloud_unencrypted
maxFileLength = 255 // for 1 byte unicode characters
maxFileLength = 255 // for 2 byte unicode characters
maxFileLength = 255 // for 3 byte unicode characters
maxFileLength = 127 // for 4 byte unicode characters
base32768isOK = true // make sure maxFileLength for 2 byte unicode chars is the same as for 1 byte characters

nielash · March 3, 2026, 1:19am

Is the (Conflict ) part literally part of the filename? (Appended by a sync client, maybe?)

If so, that would indeed make the filename undecryptable. Restoring the original filename might help.

Could be worth testing whether rclone cryptdecode can decode 㿄䈸㤦槚蝄⡘䘺欹嶃▸萰固ߊ哙ᣓ䥼禰痰㯔䅀㛞晪㯔伔闕ꂟ by itself.

rcloningnemo · March 3, 2026, 8:14am

Thanks for the pointer to rclone cryptdecode, that works fine and lets me see which two files are causing the issue (and it doesn't look like "(Conflict )" has been added to the filename). But neither of them has anything out of the ordinary about them - they've both been on my file system for ages (since 2024 in one case, 2020 in the other), and have never been flagged up in any way before. Both filenames are just alphanumeric, with a couple of dashes, underscores and dots.

As a potential extra clue, now that I can identify the problem files, I'm also finding that

rclone ls jottacloud_encrypted:path/to/files

is also giving an error/notice on the folders where the problem files live - it will list some of the files OK, and then at some point stop with

2026/03/03 08:09:00 NOTICE: Failed to ls: couldn't list files: invalid result from listStream: expected[jottacloud.stats{Folders:0, Files:0}] != actual[jottacloud.stats{Folders:1, Files:52}]

... but rclone ls works fine on other folders elsewhere on my filesystem.

I suppose I could try nuking those particular folders on the remote and resyncing them, but I'll hold fire on that in case there are other diagnostic steps you'd like me to try first of all

nielash · March 3, 2026, 9:55pm

How are you determining that (Conflict ) isn't part of the filename? I ask because the way it appears before the colon here:

suggests to me that rclone thinks it is part of the name. I'm not aware of anything in the code that would otherwise add that (Conflict ) to the log line.

To clarify: the question is whether it has been added to the encrypted filename (post-encryption), not the decrypted filename.

rcloningnemo:

2026/03/03 08:09:00 NOTICE: Failed to ls: couldn't list files: invalid result from listStream: expected[jottacloud.stats{Folders:0, Files:0}] != actual[jottacloud.stats{Folders:1, Files:52}]

This error looks specific to jottacloud.

Is it possible that jottacloud is using UTF-16 instead of UTF-8 and that is causing problems with base32768? (see note about this here.)

rcloningnemo · March 3, 2026, 11:11pm

I'm basing this off of the output of the rclone cryptdecode command, which looks like this -

峸㣢䝇狝䠟瀖❉ꏵ浟/蚏⍐㦟鄃钗髰鞚䊸✳筲翚ꀗ沥⠶倪⎌㮻ɟ/銷蟸隶唋井屰摻诙ᯛ颊址ꇠ䒡鄲迎Ⲉꂋ墴酣螎秭㪤䪖謆䊐潟 	 path/to/files/undecrypted_filename.bin

ie "(Conflict )" doesn't appear anywhere in the output (or on the local filesystem). Am I maybe not interpreting that correctly? If I try to run the following, to see if "Conflict" appears as part of any of the encrypted filenames -

rclone ls jottacloud_unencrypted: | grep -i Conflict

I just get another "failed to ls" error/notice

2026/03/03 22:48:15 NOTICE: Failed to ls: couldn't list files: invalid result from listStream: expected[jottacloud.stats{Folders:0, Files:0}] != actual[jottacloud.stats{Folders:18, Files:3420}]

I'm not using any sync client apart from straight rclone, so I can't think where else "Conflict" might come from

I'm not sure how I could check this? All I can say for sure is that this seems to be a problem that's only recently come up for me, and seems to relate to old files that would have been initially synced months ago - if what you're describing is a problem, I would have expected to see the errors (and possibly a lot more of them) before now?

nielash · March 4, 2026, 8:23am

rcloningnemo:

If I try to run the following, to see if "Conflict" appears as part of any of the encrypted filenames -
rclone ls jottacloud_unencrypted: | grep -i Conflict
I just get another "failed to ls" error/notice

This is closer to what I was thinking. But it's hard to be sure what that result is telling us, since it is erroring before it completes the list. Can you try it with lsf instead of ls, in case duplicate directories are part of the problem? There was a very similar issue here not too long ago:

One other thing you could try is running your sync again with --disable ListR

I say that because it looks like the specific error you are encountering only happens in a ListR codepath:

github.com/rclone/rclone

backend/jottacloud/jottacloud.go

78a7d9bb8


      
          			case "stats":
          				if err := decoder.DecodeElement(&expected, &se); err != nil {
          					return err
          				}
          			}
          		}
          	}
          
          	if expected.Folders != actual.Folders ||
          		expected.Files != actual.Files {
          		return fmt.Errorf("invalid result from listStream: expected[%#v] != actual[%#v]", expected, actual)
          	}
          	return nil
          }
          
          // ListR lists the objects and directories of the Fs starting
          // from dir recursively into out.
          //
          // dir should be "" to start from the root, and should not
          // have trailing slashes.
          func (f *Fs) ListR(ctx context.Context, dir string, callback fs.ListRCallback) (err error) {

--disable ListR should make it fall back to List instead (which may still fail, but probably in a different way that could give us more clues)

Well, the rclone test info --check-base32768 suggested above is where I would have started, but it looks like you already tried that and it didn't show a problem. So this may not be it. At the same time, I also see that the docs state that Jottacloud is case insensitive. I'd have assumed that base32768 would not be a good choice for a case-insensitive backend. One possible explanation is that the case insensitivity only presents a problem in the rare event of a collision. i.e. often an insensitive remote can handle hello and HELLO -- but just not both at the same time. As long as you have only one or the other, you might not notice a problem. The problem arises from treating those as interchangeable, when they are not for base32768 purposes.

One more observation about my (Conflict ) theory: the relevant log line is saying illegal base32768 data at input byte 52. And it just so happens that 㿄䈸㤦槚蝄⡘䘺欹嶃▸萰固ߊ哙ᣓ䥼禰痰㯔䅀㛞晪㯔伔闕ꂟ is exactly 52 UTF-16 bytes.

Likewise, it decodes as valid base32768, but as soon as you add a space, it chokes with illegal base32768 data at input byte 52.

(click "Run")

rcloningnemo · March 5, 2026, 8:59am

OK, problem solved!

As you thought, @nielash, the problem was that I'd somehow ended up with both 㿄䈸㤦槚蝄⡘䘺欹嶃▸萰固ߊ哙ᣓ䥼禰痰㯔䅀㛞晪㯔伔闕ꂟ and 㿄䈸㤦槚蝄⡘䘺欹嶃▸萰固ߊ哙ᣓ䥼禰痰㯔䅀㛞晪㯔伔闕ꂟ (Conflict ) on my remote filesystem, and the solution was to delete the (Conflict ) version of the file. rclone is now syncing without warnings/notices, and rclone ls also no longer gives errors. Thank you so much for your help!

The way I resolved the problem was to use the rclone gui (rclone rcd --rc-web-gui) to browse the unencrypted remote, and which didn't seem to have a problem with listing all of the files, in connection with rclone cryptdecode to figure out which subdirectories to head into. I could then use the rclone gui to delete the offending (Conflict ) files

I guess the creation of the (Conflict ) files is a bit of a mystery, but perhaps is something that the jottacloud backend (helpfully, I suppose, under normal circumstances) makes when it thinks there's a problem...?

albertony · March 5, 2026, 11:08am

Correct, Jottacloud does that. I don't remember exactly in what situations, but I remember seeing this when testing their API. One case may have been an aborted upload of a file followed by creating a directory with the same name. That was by using raw API requests, don't think/hope it was reproducible when using rclone only. Anyway, I just wanted to confirm that this is something that Jottacloud may do.

system · March 8, 2026, 11:09am

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.