I am using NextCloud 31.0.12 fpm server + nginx, and windows client 4.0.4. I noticed a interesting thing that if a file is larger than 100MB(no mater how much is the ChrunkingSize) and the same time it is in a local path that contains “%“, the client could not sync to the server and report an error. I believe this could be in Version NC32 as well.
Do you guys have the same problem?
For some reason I have to keep the “%“ in the path, I know it is not quite right to do so.
If you can specify about the error you see, and if you have log files, that might be helpful.
Also, it might be interesting which file system you are using for storing the data of the Nextcloud.
Thank you for responding me, the server is locally deployed on Ubuntu for only myself, and error prompt is as below(there is a “File_99MB.pdf“ with size 99MB in the same folder and synced with no problem):
Error
Error transferring https://nuc.local/remote.php/dav/files/tony/test/50%25DD/File_100MB.pdf -server replied: Not Found
the nextcloud.log is as below:
{"reqId":"EnxUd57Pd90VIe80D47F","level":0,"time":"2026-01-20T06:09:16+00:00","remoteAddr":"172.23.0.1","user":"tony","app":"webdav","method":"PUT","url":"/remote.php/dav/uploads/tony/376547639/00001","message":"File with name /test/50\u00dd could not be located","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.4 (build 20251215) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"31.0.12.3","clientReqId":"7e40a79c-4b9f-4993-aafc-8c985a8a7a30","exception":{"Exception":"Sabre\\DAV\\Exception\\NotFound","Message":"File with name /test/50\u00dd could not be located","Code":0,"Trace":[{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Tree.php","line":95,"function":"getChild","class":"OCA\\DAV\\Connector\\Sabre\\Directory","type":"->","args":["50\u00dd"]},{"file":"/var/www/html/apps/dav/lib/Connector/Sabre/QuotaPlugin.php","line":188,"function":"getNodeForPath","class":"Sabre\\DAV\\Tree","type":"->","args":["files/tony/test/50\u00dd"]},{"file":"/var/www/html/apps/dav/lib/Connector/Sabre/QuotaPlugin.php","line":81,"function":"getPathForDestination","class":"OCA\\DAV\\Connector\\Sabre\\QuotaPlugin","type":"->","args":["files/tony/test/50\u00dd/File_100MB.pdf"]},{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeCreateFile","class":"OCA\\DAV\\Connector\\Sabre\\QuotaPlugin","type":"->","args":["*** sensitive parameters replaced ***","*** sensitive parameters replaced ***",{"__class__":"OCA\\DAV\\Upload\\UploadFolder"},false]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":1094,"function":"emit","class":"Sabre\\DAV\\Server","type":"->","args":["beforeCreateFile",["*** sensitive parameters replaced ***","*** sensitive parameters replaced ***",{"__class__":"OCA\\DAV\\Upload\\UploadFolder"},false]]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":504,"function":"createFile","class":"Sabre\\DAV\\Server","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpPut","class":"Sabre\\DAV\\CorePlugin","type":"->","args":[{"__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":472,"function":"emit","class":"Sabre\\DAV\\Server","type":"->","args":["method:PUT",[{"__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]]},{"file":"/var/www/html/apps/dav/lib/Connector/Sabre/Server.php","line":49,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[{"__class__":"Sabre\\HTTP\\Request"},{"__class__":"Sabre\\HTTP\\Response"}]},{"file":"/var/www/html/apps/dav/lib/Server.php","line":403,"function":"start","class":"OCA\\DAV\\Connector\\Sabre\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":21,"function":"exec","class":"OCA\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/remote.php","line":145,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/var/www/html/apps/dav/lib/Connector/Sabre/Directory.php","Line":194,"message":"File with name /test/50\u00dd could not be located","exception":{},"CustomMessage":"File with name /test/50\u00dd could not be located"}}
I tried to locate and fix the problem, only to find it’s too complex for me. I overcome the problem by first uploading the files to a folder without % in path, and then move to the target folder. I think it more or less a temporary solution as I don’t have many these folders.
Hello,
now, it gets interesting. You use the desktop sync client , am I correct?
What is the name of the folder in Windows containing the file in question? Is it like 50%25DD or is there a Unicode special char in the filename?
Chris
Hi Chris,
Thank you in advance for looking into my question.
Yes I am using a windows nextcloud client 4.0.4 syncing files to the sever. The sever is an Ubuntu 24.04.3, and the nextcloud server 31.0.12 and nginx:latest is deployed in docker 28.3.3. I disabled all the plugins but the problem still there.
The folder name is “50%DD” and the path is “/test/50%DD/file_100MB.pdf”, in the client error prompt the folder name is encoded to “50%25DD”, while in the nextcloud log it says “File with name /test/50\u00dd could not be located”, the “%“ is encoded to “\u00”. My understanding is that something wrong with the encoding and decoding during chunking process.
Meanwhile, it is seems that the chunking settings are not working as well. below is the client setting, but whatever I set for the chunking(both server and client), the trigger size of the problem is 100MB without change:
chunkingNormalizedUrls=false
bulkUploadEnabled=true
maxChunkSize=107374182400 # 100G same as sever setting
minChunkSize=1073741824
maxConcurrentChunkUploads=1
timeout=3600
chunkingEnabled=true
In URLs, some characters are not allowed. E.g. umlauts like äöü in German or other special chars ê, à, ç, ş, … in French or just # and & need dedicated encoding. To do them, unicode is used in the background. The URLs must be ASCII-only for backward compatibility. Thus, there was an agreement to use the percent sign to indicate that a unicode char is going to be used. After the percent the unicode bytes are encoded as hexdecimal chars.
So, the string 50%DD has a % included that needs escaping. The %-char in unicode is theoretically \u0025. So, the url-encoded name of the folder would be 50%25DD (or I think .50%0025DD)
I suppose, that there is a bug with the chunking is there. I would suppose it to be located in the server but it might be in the client as well. I would ask you to open an issue on GitHub. Please search existing issues matching your topic before filing a new one. Please reference the issue here as well.
Thank you and have a good day.
christianlupus