Hetzner Box filename length limit

Help and Support
1

What is the problem you are having with rclone?

I get Failed to copy: Update Create failed: sftp: "Bad message" (SSH_FX_BAD_MESSAGE) when copying specific directories to Hetzner Box storage. It appears due to the filename limit of Hetzner Box which is apparently 256 bytes / chars.

This is part request for help and part for indexing for other people.

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

rclone v1.70.3
- os/version: alpine 3.22.1 (64 bit)
- os/kernel: 6.12.24-Unraid (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.24.4
- go/linking: static
- go/tags: none

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

Hetzner Storage Box

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

rclone copy -v --fast-list --checkers 3 --transfers 3 --filter "+ /[X-Zx-z]*/**" --filter "- /**" /data/files hetzner-crypt:

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

[hetzner]
type = sftp
host = XXX
user = XXX
port = 23
key_file = /config/.ssh/id_ed25519
shell_type = unix
md5sum_command = md5sum
sha1sum_command = sha1sum

[hetzner-crypt]
type = crypt
remote = hetzner:files
password = XXX
password2 = XXX

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

2025/08/19 08:22:54 DEBUG : rclone: Version "v1.70.3" starting with parameters ["rclone" "copy" "-vv" "--fast-list" "--checkers" "3" "--transfers" "3" "--filter" "+ /[X-Zx-z]*/**" "--filter" "- /**" "/data/files" "hetzner-crypt: "--log-level" "DEBUG" "--log-file=/tmp/rclone.log"]
...
2025/08/19 08:23:09 INFO  : Annoying-Dir: Set directory modification time (using DirSetModTime)
2025/08/19 08:23:09 ERROR : Attempt 3/3 failed with 12 errors and: Update Create failed: sftp: "Bad message" (SSH_FX_BAD_MESSAGE)
2025/08/19 08:23:09 INFO  : 
Transferred:              0 B / 0 B, -, 0 B/s, ETA -
Errors:                12 (retrying may help)
Checks:                 3 / 3, 100%, Listed 258
Elapsed time:        12.5s

2025/08/19 08:23:09 DEBUG : 31 go routines active
2025/08/19 08:23:09 DEBUG : sftp://your-storagebox.de:23/backup: Closing 3 unused connections
2025/08/19 08:23:09 NOTICE: Failed to copy with 12 errors: last error was: Update Create failed: sftp: "Bad message" (SSH_FX_BAD_MESSAGE)

I checked using cryptedecode –reverse and base32 and indeed those specific files have more than 256 chars. Is there anything I could do outside renaming them?

In addition, the generic error message is due to the limitations of Hetzner box ssh server?

As always thank you.

2

afiak, not a hetzner issue. that is a common error message when dealing with most any sftp server.

that flag does nothing , as sftp and local, do not support ListR

the crypt remote increases the length of names of files and directories.
using default values, if a filename is longer than 143 characters, can run into your issue.

possible workarounds:

  • do not encrypt filenames and dir names
  • obfuscate filenames and dir names
  • choose another encoding scheme for --crypt-filename-encoding, such as base32768

for a more detailed look, rclone test info remote: --all

rclone test info sbox01_sftp_23:zork --all
NOTICE: sftp://redacted@redacted.your-storagebox.de:23/zork/rclone-test-info-qekarer5/test-base32768: 0 differences found
NOTICE: sftp://redacted@redacted.your-storagebox.de:23/zork/rclone-test-info-qekarer5/test-base32768: 1028 matching files
// sbox01_sftp_23
stringNeedsEscaping = []rune{
        '/', '\x00'
}
maxFileLength = 255 // for 1 byte unicode characters
maxFileLength = 127 // for 2 byte unicode characters
maxFileLength = 85 // for 3 byte unicode characters
maxFileLength = 63 // for 4 byte unicode characters
canWriteUnnormalized = true
canReadUnnormalized   = true
canReadRenormalized   = false
canStream = true
base32768isOK = true // make sure maxFileLength for 2 byte unicode chars is the same as for 1 byte character
3

Thanks I tend to keep it there by habit.

Exactly that’s why I mentioned checking with cryptdecode –reverse to get the encoded filenames lengths.

Not possible in this scenario.

Removed previous output as I mistakenly run test info --all against my crypt remote.

rclone test info hetzner:foo --all
2025/08/20 01:33:45 NOTICE: sftp://redacted@redacted.your-storagebox.de:23/foo/rclone-test-info-jilideb9/test-base32768: 0 differences found
2025/08/20 01:33:45 NOTICE: sftp://redacted@redacted.your-storagebox.de:23/foo/rclone-test-info-jilideb9/test-base32768: 1028 matching files
// hetzner
stringNeedsEscaping = []rune{
	'/', '\x00'
}
maxFileLength = 255 // for 1 byte unicode characters
maxFileLength = 127 // for 2 byte unicode characters
maxFileLength = 85 // for 3 byte unicode characters
maxFileLength = 63 // for 4 byte unicode characters
canWriteUnnormalized = true
canReadUnnormalized   = true
canReadRenormalized   = false
canStream = true
base32768isOK = true // make sure maxFileLength for 2 byte unicode chars is the same as for 1 byte characters

As in your output for base32768 it mentions to check that 1 & 2 byte maxFileLength are the same and they differ which means it is unsupported? Trying to copy a filename with 144 characters (which won’t work with base32 as we covered) using --crypt-filename-encoding base32768 produces the same error. Is it different on your end?

4

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