Crypt remote problems, limitations?

Help and Support
1

Hi, i've been saving my data from idriveE2 to move to other provider, also backing up to 2x HDDs. On idrive all was unencrypted, for the other provider, and HDDs i use the same crypt remote. both copies made directly from idrivee2.

So idrivee2-> 1fichier using encryption, idrivee2-> hdd using same encryption, hdd > other hdd using same encryption (this is when i've noticed the errors, also tried to open the same files from the 1fichier, and there same problem).

Some very important files seem to be corrupted on both, same files.
When copying from idriveE2 there wasn't any error shown by rclone, but now when i try to open them from the other provider, or the HDDs, i can't.

The strange thing is, this corruption happens mostly with mkv (matroska) files, but next to these mkv files, the mp4 and other files are playable, independent from size.
But also there are mov files corrupted, some restic backup files, and a 36 gbyte raw disk clone file (hogymeglegyen20210508_2004.ksgp).

I see such errors:

2023/12/11 10:16:19 NOTICE: 9du82tg6at2qv0bjl5mjoc96ho/9v6hrqv9b57941m6k3u6dpjovq6n13m22t0e507ib1nbr51jpe39psptsdudb8gnnsmpd0llrfjn2j7cuirsqu1iiab77g8oq32tntg: Removing partially written file on error: failed to authenticate decrypted block - bad password?
2023/12/11 10:16:19 ERROR : ment/hogymeglegyen20210508_2004.ksgp: Failed to copy: failed to authenticate decrypted block - bad password?
2023/12/11 12:29:25 NOTICE: 95vau4pqssc8ghf5ibf3qk82co/9q1863ckhatj0hbl080ra0t9civn7d9h1rqkl3375hqpplp8p02tekbk3q1vnb8bvhb99g59r3jpu: Removing partially written file on error: failed to authenticate decrypted block - bad password?
2023/12/11 12:29:25 ERROR : moccvid/20180921_203725.MOV: Failed to copy: failed to authenticate decrypted block - bad password?
2023/12/11 13:07:04 ERROR : upszi/inasz/mipi/181703_juvkd.mkv: Failed to copy: failed to open source object: not an encrypted file - bad magic string
2023/12/11 13:56:19 ERROR : moccvid/20191026/20191026_133056 Pilisvörösvár-Dobogókő-Esztergom felé.MOV: Failed to copy: failed to authenticate decrypted block - bad password?

rclone versions (copying is done with a win pc, and 2 linux pcs, always taking care to avoid concurrent writes, only one machine was doing the copy)

win:

rclone v1.65.0
- os/version: Microsoft Windows 11 Pro 22H2 (64 bit)
- os/kernel: 10.0.22621.2715 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.21.4
- go/linking: static
- go/tags: cmount

linux 1 (home server):

rclone v1.65.0
- os/version: ubuntu 20.04 (64 bit)
- os/kernel: 5.4.0-163-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.21.4
- go/linking: static
- go/tags: none

linux 2 (laptop):

rclone v1.65.0
- os/version: linuxmint 21.2 (64 bit)
- os/kernel: 5.15.0-91-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.21.4
- go/linking: static
- go/tags: none

remotes used:

downloading from:

[idrives3test]
type = s3
provider = IDrive
access_key_id = XXX
secret_access_key = XXX
acl = private
endpoint = i6m4.fra.idrivee2-26.com
chunk_size = 16Mi
upload_concurrency = 8
multi_thread_streams = 8

other provider remote (used only by the crypt remote):

[1fichier]
type = fichier
api_key = XXX

crypt remotes (all of these are duplicated from the first with "copy remote" in rclone config, only the remote path is changed) :

[backupkript1fichier]
type = crypt
remote = 1fichier:/bigtar/
password = XXX
password2 = XXX

[backupkript_I]
type = crypt
remote = phydisk:i:/bck/
password = XXX
password2 = XXX

[backupkript_O]
type = crypt
remote = phydisk:o:/bck/
password = XXX
password2 = XXX

physical disk remote

[phydisk]
type = local

commands

idrive-> 1fichier encrypt

rclone copy idrives3test://bigtar/ backupkript1fichier: -P  --modify-window 5s --order-by size,desc

idrive -> hdd encrypt:

rclone copy idrives3test:bigtar/ backupkript_I: --exclude="film/**" --multi-thread-streams 8 --s3-upload-concurrency 8 --s3-chunk-size 16M --modify-window=10s -P -vv

hdd to hdd:
rclone copy backupkript_I:/ backupkript_O:/

EDIT:
I've now tried this on windows machine:

rclone mount "backupkript1fichier:" x: --vfs-fast-fingerprint --dir-cache-time 5m --vfs-cache-mode=minimal -v

and opened some of the problematic files, those are opening correctly!

on linux machine this runs:

nohup rclone serve webdav backupkript1fichier:/ --addr :8889 --dir-cache-time 3h --vfs-read-chunk-size=16Mi --vfs-fast-fingerprint --vfs-cache-mode=minimal --track-renames --user user --pass xxxxxxx &> ~/webdavallz.txt&

the mkv files don't open, however it can be because of limitations of webdav. No error in log.

But still the copy from HDD to HDD have the errors above, while as i mentioned same crypt used, also exactly the same HDD with same exFAT FS.
I've saw that the very long filenames which are ok on the first HDD, causing the usual too long filename errors (Failed to copy: The filename, directory name, or volume label syntax is incorrect. because of exFAT 255 limit) on copying to the second HDD.

Its strange because everything is the same, also checked the encrypted file and folder names, those are the same too, so the encryption is surely the same, with same lenght filenames, and same lenght paths.

2

well, that command has a syntax error in it
user--pass should be user --pass

3

there isn't else i couldn't browse for the problematic file. Just i deleted the space too, when removing the real user/pass :slight_smile:

4

ok, you have a complex setup. i did a quick scan and noticed that typo.

for each rclone copy, i would run rclone check or rclone cryptcheck with a debug log file.

5

I don't think that will help, as i wrote those files are ok if i open them with rclone mount, but not if i do rclone copy/sync/serve webdav, so the file itself is correct.
But i'll try once the copies are done.

BTW what "Checks" counter means on sync/copy? I'm copying, syncing from an idrive bucket that contains 192000 objects, the target even less (which are from the idrive), yet the "Checks" count on copy is at 500000 and counting.

6

for each file, rclone "compares" the source file against the dest file.

7

It seems not, as i wrote there are only 192000 files in that bucket, yet the checking count gone up to 500000.

BTW i thought rclone copy and sync checks each uploaded file, and flags the copy "done" only when the hashes matching, that's why the progress stands at 100% for long time for bigger files. But it seems it isn't as running cryptcheck shows multiple files with differing hashes :frowning:

8

yes, that is what i thought would happen.

at this point, you do not have any rclone debug logs to look at.

fwiw, start over, for each rclone sync|copy command

  1. use a debug log file.
  2. run rclone check|cryptcheck with a debug log file.
9

But the differing hash files are not the same ones that are erroring on copy from hdd to identical hdd, with same folder structure, same fs, same encryption, while the files are correct on the source.
For hdd backups it seems i should use veracrypt (for platform compatibility, as LUKS not really supported on win) encrypted partition, with NTFS file system in it (its not much slower than exfat on linux), and rclone crypt will be only used for cloud storage.

10

ok, good luck with that.

11

it seems rclone crypt have some problems even on NTFS file system.
I'm getting these kind of errors: 2023/12/20 15:55:44 ERROR : ASOT/ASOT_380/(23) [Peter Martijn Wijnia pres. Majesta vs. DJ Shah feat. Adrina Thorpe] Not The End vs. Who Will Find Me (Armin van Buuren Mashup).mp3: Failed to copy: The filename, directory name, or volume label syntax is incorrect. 2023/12/20 15:55:44 INFO : ASOT/ASOT_380/(23) [Peter Martijn Wijnia pres. Majesta vs. DJ Shah feat. Adrina Thorpe] Not The End vs. Who Will Find Me (Armin van Buuren Mashup).mp3.pagifer3.partial: Failed to remove failed partial copy: CreateFile \\?\o:\bck\lni2ouqtbhnjk3ev20pv766hns\vk0c9ha4rcaev5u5okm81snf8s\le32fekc7h5s1g1iqoashqh510\qb43qkaqun7m07lntfhfk8knmg\kv1e4s904aqs6v1trgaqk30t1eubd8m5kujns5rm0aoud8khutqo3uc5m2ti7rerdb0jd2m22qlnqp80bdcsb4src8q7ftp5vqpt40la3ebnhvpv8ndpd9tr6phfqr36qdnehe2gfap5q96nspulb26did78e3qmc1m43j2nf4ke4jp3tblerev79vaus3e6rhr41o6hu6ag2ge5nsk4aafiklciejmvm5iqemgi6ed794sir538620rdrcf7slu: The filename, directory name, or volume label syntax is incorrect. 2023/12/20 15:55:44 ERROR : ASOT/ASOT_363/(17) [Jochen Miller vs. Armin van Buuren feat. Sharon den Adel] Lost Connection In And Out Of Love (Armin van Buuren) [TOTW].mp3: Failed to copy: The filename, directory name, or volume label syntax is incorrect. 2023/12/20 15:55:44 INFO : ASOT/ASOT_363/(17) [Jochen Miller vs. Armin van Buuren feat. Sharon den Adel] Lost Connection In And Out Of Love (Armin van Buuren) [TOTW].mp3.jazacek4.partial: Failed to remove failed partial copy: CreateFile \\?\o:\bck\lni2ouqtbhnjk3ev20pv766hns\vk0c9ha4rcaev5u5okm81snf8s\le32fekc7h5s1g1iqoashqh510\390hrk9sqvc2f049npj7jshc6g\birul8bsps5mc2ae809ut45hqc1667oej7gepuqs26eqa0vns0q65t9197e6l49cgif07b37opbepqbr84i1vs26qniam0ssbkfiopsmu1rg7vl3u77egqpk2dblh1uusv1aphe0ch9ntegdckuc43hf4jp6u7efe72dam5iu3ppn3po3m892mog41dodggctstg5n3gc73fmkalnujasbu55ivehvv7u498heon0c6010e2k9nuigdouqujeaoh: The filename, directory name, or volume label syntax is incorrect. 2023/12/20 15:55:44 ERROR : ASOT/ASOT_379/(09) [Blake Jarrell pres. Trasher vs. Laurent Garnier] Hosoi (Simon & Shaker Remix) vs. The Man With The Red Face (Saxophone) (AvB Mashup).mp3: Failed to copy: The filename, directory name, or volume label syntax is incorrect. 2023/12/20 15:55:44 INFO : ASOT/ASOT_379/(09) [Blake Jarrell pres. Trasher vs. Laurent Garnier] Hosoi (Simon & Shaker Remix) vs. The Man With The Red Face (Saxophone) (AvB Mashup).mp3.cutaris3.partial: Failed to remove failed partial copy: CreateFile \\?\o:\bck\lni2ouqtbhnjk3ev20pv766hns\vk0c9ha4rcaev5u5okm81snf8s\le32fekc7h5s1g1iqoashqh510\i82d5pn3a6ae6kgab75de2mj1g\cmbhr3oslng8rgoufgeuclsm028e2iegrd619ho7kjvr47ne1hmcgou9djgepts8nbkqmv778t0tisjin81h6qv9ksl2mqvea9kc1ie9p1did9ggta08qc6ndgf2qp2radj32c9fb2e8rh26jsdpclveu6a0n5gjju054scet6hsruivr7ai44h3rp689i9q58klo844ts8jsu9lr37rcpcmkvpfk84npuu6lonf2pomjcmrvol7qgbjl821ddgj: The filename, directory name, or volume label syntax is incorrect.

This was already set: https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/The-Windows-10-default-path-length-limitation-MAX-PATH-is-256-characters.html

And set this too: How to enable NTFS long paths in Windows - Backupery
I've not restarted win yet, but it seems its the same as the registry value, so probably won't solve the problem.

But it doesn't looks nice that crypt is creating such extreme long filenames. The only way to avoid this is using only obfuscation on filenames? (except of shortening filenames that cause error)

Of coure online on 1fichier with same encryption and directory structure the such long filenames arent problem.

12

You are using default base32 files' names encoding - it leads to encrypted names to be much longer than originals but works on any filesystem and cloud storage - it uses basic ASCII characters and does not care about their case.

There are two other options here: base64 and base32768. The latter is extremely efficient in terms of files' names length.

I am not sure if base32768 is suitable for Windows NTFS file system (it is for Linux ext4 and macOS APFS). You can check it yourself by running:

rclone test info --check-length --check-base32768 /path/to/test/directory

Here sample output for APFS:

$ rclone test info --check-length --check-base32768 .
// local
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

It tells you that base32768isOK = true meaning that all needed characters are supported. In addition maxFileLength for 2 byte unicode chars is the same as for 1 byte characters. Both together indicate that on this filesystem I can use filename_encoding = base32768 and save much longer names that with default base32. In practice max name length can be assumed in this case the same as in unencrypted file system.

13

how base32768 encoding works? I think the first byte value identifies the encoding like in base64, so adding the encoding parameter to read back the files isn't needed, but still it would be easier and nicer to be able to set the default encoding for the crypt remote.

What happens if i set filename_encoding = base32768 for a crypt remote that has filenames in default (base32) and do a copy, or sync? It will add the newly copied files with base32768 and leave others, or will convert all filenames to base32768?

14

Nope. There is no first byte indicating anything. Names encoding is set in remote config. If nothing is set then base32 is used by default.

Files and directories with different then set in config encoding won't be readable. You can create new remote with different encoding and move all content from old remote. As long as both are within the same remote and you use the same password(s) for both crypts then only names will be re-encoded - content stays the same so all operation is fast.

15

then i'll just shorten the filenames, as this approach can lead to more problems.

But there is another problem, not with the length of filenames: there are some files that are can't be uploaded to 1fichier through my crypt remote, as always ends with Failed to copy: upload response not found copy/sync/mount all the same.
Always the same files, while nothing special with those. Just few megabytes, the name have only ASCII chars, but even if i rename to totally random names like "fsdgdgsdgsdgsdghwgwe.mp3", or "2324.mp3" same happens.
I've tried uploading to 1fichier without crypt, it works. Mounted physical drive too with the crypt, and the "upload" there worked too, so only happens when i try to upload to 1fichier with crypt.

Here is a try with rclone mount backupkript1fichier:/ ~/cloud/ --vfs-cache-mode minimal -vv :

2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: >Write: written=131072, err=<nil>
2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: Write: len=131072, offset=129761280
2023/12/21 14:00:21 DEBUG : dasdas.mp3(0xc000036140): _writeAt: size=131072, off=129761280
2023/12/21 14:00:21 DEBUG : dasdas.mp3(0xc000036140): >_writeAt: n=131072, err=<nil>
2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: >Write: written=131072, err=<nil>
2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: Write: len=98924, offset=129892352
2023/12/21 14:00:21 DEBUG : dasdas.mp3(0xc000036140): _writeAt: size=98924, off=129892352
2023/12/21 14:00:21 DEBUG : dasdas.mp3(0xc000036140): >_writeAt: n=98924, err=<nil>
2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: >Write: written=98924, err=<nil>
2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: Flush: 
2023/12/21 14:00:21 DEBUG : dasdas.mp3(0xc000036140): RWFileHandle.Flush
2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: >Flush: err=<nil>
2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: Release: 
2023/12/21 14:00:21 DEBUG : dasdas.mp3(0xc000036140): RWFileHandle.Release
2023/12/21 14:00:21 DEBUG : dasdas.mp3(0xc000036140): close: 
2023/12/21 14:00:21 DEBUG : dasdas.mp3: Setattr: a=Setattr [ID=0x12dc Node=0x426 Uid=1000 Gid=1000 Pid=17954] atime=2023-12-21 14:00:21 +0100 CET mtime=2023-03-16 22:10:26 +0100 CET handle=INVALID-0x0
2023/12/21 14:00:21 DEBUG : dasdas.mp3: vfs cache: setting modification time to 2023-12-21 14:00:21.459483385 +0100 CET m=+70.600062854
2023/12/21 14:00:21 INFO  : dasdas.mp3: vfs cache: queuing for upload in 5s
2023/12/21 14:00:21 DEBUG : dasdas.mp3: vfs cache: setting modification time to 2023-03-16 22:10:26 +0100 CET
2023/12/21 14:00:21 DEBUG : dasdas.mp3: >Setattr: err=<nil>
2023/12/21 14:00:21 DEBUG : dasdas.mp3: Attr: 
2023/12/21 14:00:21 DEBUG : dasdas.mp3: Set virtual modtime to 2023-03-16 22:10:26 +0100 CET
2023/12/21 14:00:21 DEBUG : dasdas.mp3: >Attr: a=valid=1s ino=0 size=129991276 mode=-rw-rw-r--, err=<nil>
2023/12/21 14:00:21 DEBUG : dasdas.mp3(0xc000036140): >close: err=<nil>
2023/12/21 14:00:21 DEBUG : &{dasdas.mp3 (rw)}: >Release: err=<nil>
2023/12/21 14:00:21 DEBUG : dasdas.mp3: Setattr: a=Setattr [ID=0x12de Node=0x426 Uid=1000 Gid=1000 Pid=17954] mode=-rw-rw-r-- handle=INVALID-0x0
2023/12/21 14:00:21 DEBUG : dasdas.mp3: >Setattr: err=<nil>
2023/12/21 14:00:21 DEBUG : dasdas.mp3: Attr: 
2023/12/21 14:00:21 DEBUG : dasdas.mp3: >Attr: a=valid=1s ino=0 size=129991276 mode=-rw-rw-r--, err=<nil>
2023/12/21 14:00:21 DEBUG : : Statfs: 
2023/12/21 14:00:21 DEBUG : : >Statfs: stat={Blocks:536870912 Bfree:536870912 Bavail:536870912 Files:1000000000 Ffree:1000000000 Bsize:4096 Namelen:255 Frsize:4096}, err=<nil>
2023/12/21 14:00:26 DEBUG : dasdas.mp3: vfs cache: starting upload
2023/12/21 14:00:40 ERROR : dasdas.mp3: Failed to copy: upload response not found
2023/12/21 14:00:40 ERROR : dasdas.mp3: vfs cache: failed to upload try #1, will retry in 10s: vfs cache: failed to transfer file from cache to remote: upload response not found
2023/12/21 14:00:50 DEBUG : dasdas.mp3: vfs cache: starting upload
2023/12/21 14:01:02 ERROR : dasdas.mp3: Failed to copy: upload response not found
2023/12/21 14:01:02 ERROR : dasdas.mp3: vfs cache: failed to upload try #2, will retry in 20s: vfs cache: failed to transfer file from cache to remote: upload response not found
2023/12/21 14:01:14 DEBUG : vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item dasdas.mp3 not removed, freed 0 bytes
2023/12/21 14:01:14 INFO  : vfs cache: cleaned: objects 1 (was 1) in use 1, to upload 1, uploading 0, total size 123.969Mi (was 123.969Mi)
2023/12/21 14:01:22 DEBUG : dasdas.mp3: vfs cache: starting upload
2023/12/21 14:01:36 ERROR : dasdas.mp3: Failed to copy: upload response not found
2023/12/21 14:01:36 ERROR : dasdas.mp3: vfs cache: failed to upload try #3, will retry in 40s: vfs cache: failed to transfer file from cache to remote: upload response not found

What can be the problem? I'll try to upload to other clouds with same settings, and will try to modify the metadata of these mp3s to see if a little change in file content solves it.

Edit: if i try it with -P i see the files are uploaded completely then at the end Failed to copy: upload response not found

the crypt is the same as above, all default crypt with a ~30 char alphanumeric password with ASCII chars, and a salt ("password2") same kind but just about 10 chars.

16

Try to use --vfs-cache-mode writes so rclone will have a chance to retry.

I am using multiple remotes with crypt and have none of the issues you experience.

Maybe something is broken with 1fichier... never used this one so have no idea what quirks it has.

17
  1. find a small file that fails to copy
  2. rclone copy --dump=headers -vv that file and post the full debug log
18

minimal is enough to make it retry, and did retry for each upload tries.
In total these files were retried to upload about 20-50 times for each in the past 6 days.

So it seems the rclone crypt+remote are not reliable.
I also have 140000 other files uploaded correctly to same remote with same crypt, but these few files cant be, so it cant be fully trusted.

19 
rclone copy "/home/server1/05 [Wamdue Project] King Of My Castle (Sander van Doorn Dub Mix).mp3" backupkript1fichier:/zenék/Trance/ASOT/ASOT_298/ -P -vv --exclude=fgffilm/** --exclude=mentitos/** --exclude=dfgdfmiko/p/** --modify-window 5s --order-by size,mixed,50 --dump=headers --retries 1
2023/12/21 18:55:31 DEBUG : rclone: Version "v1.65.0" starting with parameters ["rclone" "copy" "/home/server1/05 [Wamdue Project] King Of My Castle (Sander van Doorn Dub Mix).mp3" "backupkript1fichier:/zenék/Trance/ASOT/ASOT_298/" "-P" "-vv" "--exclude=fgffilm/**" "--exclude=mentitos/**" "--exclude=dfgdfmiko/p/**" "--modify-window" "5s" "--order-by" "size,mixed,50" "--dump=headers" "--retries" "1"]
2023/12/21 18:55:31 DEBUG : Creating backend with remote "/home/server1/05 [Wamdue Project] King Of My Castle (Sander van Doorn Dub Mix).mp3"
2023/12/21 18:55:31 DEBUG : Using config file from "/home/server1/.config/rclone/rclone.conf"
2023/12/21 18:55:31 DEBUG : fs cache: adding new entry for parent of "/home/server1/05 [Wamdue Project] King Of My Castle (Sander van Doorn Dub Mix).mp3", "/home/server1"
2023/12/21 18:55:31 DEBUG : Creating backend with remote "backupkript1fichier:/zenék/Trance/ASOT/ASOT_298/"
2023/12/21 18:55:31 DEBUG : Creating backend with remote "1fichier:/bigtar/lni2ouqtbhnjk3ev20pv766hns/vk0c9ha4rcaev5u5okm81snf8s/le32fekc7h5s1g1iqoashqh510/9ga392dgjqfrkbe0lhho0htbi4"
2023/12/21 18:55:31 DEBUG : You have specified to dump information. Please be noted that the Accept-Encoding as shown may not be correct in the request and the response may not show Content-Encoding if the go standard libraries auto gzip encoding was in effect. In this case the body of the request will be gunzipped before showing it.
2023/12/21 18:55:31 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:31 DEBUG : HTTP REQUEST (req 0xc00077f100)
2023/12/21 18:55:31 DEBUG : POST /v1/folder/ls.cgi HTTP/1.1
Host: api.1fichier.com
User-Agent: rclone/v1.65.0
Content-Length: 15
Authorization: XXXX
Content-Type: application/json
Accept-Encoding: gzip

2023/12/21 18:55:31 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:31 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:31 DEBUG : HTTP RESPONSE (req 0xc00077f100)
2023/12/21 18:55:31 DEBUG : HTTP/2.0 200 OK
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:33 GMT
Server: nginx
Vary: Accept-Encoding

2023/12/21 18:55:31 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:32 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:32 DEBUG : HTTP REQUEST (req 0xc00092e100)
2023/12/21 18:55:32 DEBUG : POST /v1/folder/ls.cgi HTTP/1.1
Host: api.1fichier.com
User-Agent: rclone/v1.65.0
Content-Length: 21
Authorization: XXXX
Content-Type: application/json
Accept-Encoding: gzip

2023/12/21 18:55:32 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:32 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:32 DEBUG : HTTP RESPONSE (req 0xc00092e100)
2023/12/21 18:55:32 DEBUG : HTTP/2.0 200 OK
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:33 GMT
Server: nginx
Vary: Accept-Encoding

2023/12/21 18:55:32 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:32 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:32 DEBUG : HTTP REQUEST (req 0xc00092e400)
2023/12/21 18:55:32 DEBUG : POST /v1/folder/ls.cgi HTTP/1.1
Host: api.1fichier.com
User-Agent: rclone/v1.65.0
Content-Length: 21
Authorization: XXXX
Content-Type: application/json
Accept-Encoding: gzip

2023/12/21 18:55:32 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:32 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:32 DEBUG : HTTP RESPONSE (req 0xc00092e400)
2023/12/21 18:55:32 DEBUG : HTTP/2.0 200 OK
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:34 GMT
Server: nginx
Vary: Accept-Encoding

2023/12/21 18:55:32 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:32 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:32 DEBUG : HTTP REQUEST (req 0xc000050100)
2023/12/21 18:55:32 DEBUG : POST /v1/folder/ls.cgi HTTP/1.1
Host: api.1fichier.com
User-Agent: rclone/v1.65.0
Content-Length: 21
Authorization: XXXX
Content-Type: application/json
Accept-Encoding: gzip

2023/12/21 18:55:32 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:32 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:32 DEBUG : HTTP RESPONSE (req 0xc000050100)
2023/12/21 18:55:32 DEBUG : HTTP/2.0 200 OK
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:34 GMT
Server: nginx
Vary: Accept-Encoding

2023/12/21 18:55:32 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:33 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:33 DEBUG : HTTP REQUEST (req 0xc00092e900)
2023/12/21 18:55:33 DEBUG : POST /v1/folder/ls.cgi HTTP/1.1
Host: api.1fichier.com
User-Agent: rclone/v1.65.0
Content-Length: 21
Authorization: XXXX
Content-Type: application/json
Accept-Encoding: gzip

2023/12/21 18:55:33 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:33 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:33 DEBUG : HTTP RESPONSE (req 0xc00092e900)
2023/12/21 18:55:33 DEBUG : HTTP/2.0 200 OK
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:35 GMT
Server: nginx
Vary: Accept-Encoding

2023/12/21 18:55:33 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:33 DEBUG : fs cache: renaming cache item "1fichier:/bigtar/lni2ouqtbhnjk3ev20pv766hns/vk0c9ha4rcaev5u5okm81snf8s/le32fekc7h5s1g1iqoashqh510/9ga392dgjqfrkbe0lhho0htbi4" to be canonical "1fichier:bigtar/lni2ouqtbhnjk3ev20pv766hns/vk0c9ha4rcaev5u5okm81snf8s/le32fekc7h5s1g1iqoashqh510/9ga392dgjqfrkbe0lhho0htbi4"
2023/12/21 18:55:33 DEBUG : fs cache: switching user supplied name "1fichier:/bigtar/lni2ouqtbhnjk3ev20pv766hns/vk0c9ha4rcaev5u5okm81snf8s/le32fekc7h5s1g1iqoashqh510/9ga392dgjqfrkbe0lhho0htbi4" for canonical name "1fichier:bigtar/lni2ouqtbhnjk3ev20pv766hns/vk0c9ha4rcaev5u5okm81snf8s/le32fekc7h5s1g1iqoashqh510/9ga392dgjqfrkbe0lhho0htbi4"
2023/12/21 18:55:33 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:33 DEBUG : HTTP REQUEST (req 0xc00092ee00)
2023/12/21 18:55:33 DEBUG : POST /v1/file/ls.cgi HTTP/1.1
Host: api.1fichier.com
User-Agent: rclone/v1.65.0
Content-Length: 21
Authorization: XXXX
Content-Type: application/json
Accept-Encoding: gzip
2023/12/21 18:55:33 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:33 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:33 DEBUG : HTTP RESPONSE (req 0xc00092ee00)
2023/12/21 18:55:33 DEBUG : HTTP/2.0 200 OK
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:35 GMT
Server: nginx
Vary: Accept-Encoding
2023/12/21 18:55:33 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:33 DEBUG : 05 [Wamdue Project] King Of My Castle (Sander van Doorn Dub Mix).mp3: Need to transfer - File not found at Destination
2023/12/21 18:55:34 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:34 DEBUG : HTTP REQUEST (req 0xc000050c00)
2023/12/21 18:55:34 DEBUG : POST /v1/file/ls.cgi HTTP/1.1
Host: api.1fichier.com
User-Agent: rclone/v1.65.0
Content-Length: 21
Authorization: XXXX
Content-Type: application/json
Accept-Encoding: gzip
2023/12/21 18:55:34 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:34 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:34 DEBUG : HTTP RESPONSE (req 0xc000050c00)
2023/12/21 18:55:34 DEBUG : HTTP/2.0 200 OK
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:35 GMT
Server: nginx
Vary: Accept-Encoding
2023/12/21 18:55:34 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:34 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:34 DEBUG : HTTP REQUEST (req 0xc00092f700)
2023/12/21 18:55:34 DEBUG : GET /v1/upload/get_upload_server.cgi HTTP/1.1
Host: api.1fichier.com
User-Agent: rclone/v1.65.0
Authorization: XXXX
Content-Type: application/json
Accept-Encoding: gzip
2023/12/21 18:55:34 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:34 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:34 DEBUG : HTTP RESPONSE (req 0xc00092f700)
2023/12/21 18:55:34 DEBUG : HTTP/2.0 200 OK
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:36 GMT
Server: nginx
Vary: Accept-Encoding
2023/12/21 18:55:34 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:34 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:34 DEBUG : HTTP REQUEST (req 0xc00092fa00)
2023/12/21 18:55:34 DEBUG : POST /upload.cgi?id=wFDUE5hNAc HTTP/1.1
Host: up2.1fichier.com
User-Agent: rclone/v1.65.0
Content-Length: 8388664
Authorization: XXXX
Content-Type: multipart/form-data; boundary=7312914e53b22525a229414c87cf4d72eed739003ac914861a938e872642
Accept-Encoding: gzip
2023/12/21 18:55:34 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:36 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:36 DEBUG : HTTP RESPONSE (req 0xc00092fa00)
2023/12/21 18:55:36 DEBUG : HTTP/1.1 200 200
Connection: close
Content-Type: text/html
Date: Thu, 21 Dec 2023 17:55:36 GMT
Server: [Jul  6 2023 10:15:38]
2023/12/21 18:55:36 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:37 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:37 DEBUG : HTTP REQUEST (req 0xc00067dc00)
2023/12/21 18:55:37 DEBUG : GET /end.pl?xid=wFDUE5hNAc HTTP/1.1
Host: up2.1fichier.com
User-Agent: rclone/v1.65.0
Authorization: XXXX
Json: 1
Accept-Encoding: gzip
2023/12/21 18:55:37 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2023/12/21 18:55:38 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:38 DEBUG : HTTP RESPONSE (req 0xc00067dc00)
2023/12/21 18:55:38 DEBUG : HTTP/1.1 200 OK
Connection: close
Cache-Control: no-cache, no-store, must-revalidate
Content-Type: application/json; charset=utf-8
Date: Thu, 21 Dec 2023 17:55:39 GMT
Expires: 0
Pragma: no-cache
Server: [Jul  6 2023 10:15:38]
2023/12/21 18:55:38 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2023/12/21 18:55:38 ERROR : 05 [Wamdue Project] King Of My Castle (Sander van Doorn Dub Mix).mp3: Failed to copy: upload response not found
2023/12/21 18:55:38 ERROR : Attempt 1/1 failed with 1 errors and: upload response not found
Transferred:        8.000 MiB / 8.000 MiB, 100%, 2.000 MiB/s, ETA 0s
Errors:                 1 (retrying may help)
Elapsed time:         7.0s
2023/12/21 18:55:38 INFO  : 
Transferred:        8.000 MiB / 8.000 MiB, 100%, 2.000 MiB/s, ETA 0s
Errors:                 1 (retrying may help)
Elapsed time:         7.0s

2023/12/21 18:55:38 DEBUG : 7 go routines active
2023/12/21 18:55:38 Failed to copy: upload response not found

This is one

Edit: OMG changing ID3 metadata didnt solved it, but now after shortening the filename it's uploaded! BUT there are other files there with even longer filenames than the original :face_with_spiral_eyes:
BUT if i upload the file with short name, and then rename to the original name in the mount,it works :skull:

05 [Wamdue Project] King Of My Castle (Sander van Doorn Dub Mix).mp3
20

what is the exact filename?

very strange indeed.