Server replied: Bad request. (Filename Problem?)

Hewal · November 29, 2024, 2:13pm

Hi, i get a bad request error on my hosted Nextcloud (via Hetzner).

Nextcloud Server version (e.g., 29.x.x):
- 29.0.9
Operating system and version (e.g., Ubuntu 24.04):
- Win11 Pro 23H2

As my Instance is hostet, i’m not able to update to a newer version (this is done by hetzner)

I have a maybe to long Filename and it’s there not possible to sync it to my nextcloud. After a backup of my E-Mail software i get this Error:

Zusammenfassung

Error transferring https://storage.XXX.de/remote.php/
dav/files/Hewal/Privat/Datensicherung/emClient/eMails/Alle
Mails/hewal@XXX.de/Gesendete Elemente/2024-04-08
15-21-31
unsubscribe_SqIBOHgkTLunvMuTILmgsxcYd0xDuWZmBKtD7hoV7e

server replied: Bad Request

i have tried to delete and rename this file on Windows, but it’s seems to be blocked from the nextcloud Client. After try to delete / change name there is no error, but the file has same name (by trying to change name) or is still there (after trying do delete).

Is there any solution?

tflidd · November 29, 2024, 3:27pm

There are some characters that are not supported in Windows (Windows illegal filename characters - can't find the github bug report) but I don’t see any of them in your URL. And the path should not be longer than 255 characters (File names too long - issue with NTFS filename compliance), including folders. But it is not the case either.

If the client blocks it, why do you get a bad server request (= the client is trying to upload)?

I was able to sync such a file (between date and hour I put a space):

It’s NC 30.

Hewal · November 29, 2024, 4:07pm

Hi, you checked only the filename. i think the whole path is too long:

"Privat/Datensicherung/emClient/eMails/Alle Mails/hewal@xx-xxxxxxxx.de/Gesendete Elemente//2024-04-08 15-21-31 unsubscribe_SqIBOHgkTLunvMuTILmgsxcYd0xDuWZmBKtD7hoV7eU ~_ eyAicmNwdF90byl6ICJoZXdhbEBzZy1kaWdpdGFscy5kZSlsICJ0ZW5hbnRfaWQiOiAic3BjliwglmN1c3RvbWVyX2lkljogljlxODE3MSlslCJtZXNzYWdIX2lkljogljY2MTA3ZDA2MTQ2NjU4ZTE1MTViliwgInN1YmFjY291bn.eml

The Problem is, i can’t edit the filename and i can’t delete the file… nothing happens (for both ways).

i had the same issue with the inbox backup. there i deletet the whole parent folder and the problem was solved.

But i think this is not the way it should work, because other files maybe are needed, therefore deleting all files is not such good solution

Any idea how to fix it?

tflidd · November 29, 2024, 4:57pm

I cannot even create file with such a name (on Win10, NTFS file system), even with a script I get this error:
OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: 'C:\\DATA\\Nextcloud\\test_upload\\hewal@XXX.de\\test.txt' -> 'C:\\DATA\\Nextcloud\\test_upload\\hewal@XXX.de\\2024-04-08 15-21-31 unsubscribe_SqIBOHgkTLunvMuTILmgsxcYd0xDuWZmBKtD7hoV7eU ~_ eyAicmNwdF90byl6ICJoZXdhbEBzZy1kaWdpdGFscy5kZSlsICJ0ZW5hbnRfaWQiOiAic3BjliwglmN1c3RvbWVyX2lkljogljlxODE3MSlslCJtZXNzYWdIX2lkljogljY2MTA3ZDA2MTQ2NjU4ZTE1MTViliwgInN1YmFjY291bn.eml'

So I cannot test how to do that. If you put the file into a different folder (outside Nextcloud), you can rename it?

Hewal · November 29, 2024, 5:53pm

no, i was not able to do anything with this file in the gui. ChatGPT gave me the tip to delete it with cmd, this worked. Now the error is away.

ChatGPT gives me a Registry Key to enable long Pathes in Windows, too. i added it (after deleting) to prevent such errors in the future.

Are there any restriction about patch length in Nextcloud?

tflidd · November 30, 2024, 10:31am

For characters in filenames they have something in place, for the path length I am not sure, but it seems so, there are a few items in the bug tracker:

github.com/nextcloud/server

Error reporting for too long filepaths (>255 chars)

opened 07:07AM - 19 Jun 18 UTC

jzaers

bug 0. Needs triage feature: files 25-feedback hotspot: filename handling

### Steps to reproduce 1. Use filenames with a resulting path longer than 255 c…haracters 2. This seems to result in various strange side effects like move not executed correctly and the following error message: ``` {"reqId":"xZAVDUDUMFn0yANyU6rA","level":4,"time":"2018-06-14T06:52:08+00:00","remoteAddr":"10.0.50.4","user":"87c48f84-4b31-4c8e-aac8-1c554f1b500b","app":"webdav","method":"MOVE","url":"\/owncloud\/remote.php\/dav\/files\/LONG_FILENAME_REPLACED_WITH_247_CHARACTERS","message":"Exception: {\"Exception\":\"Doctrine\\\\DBAL\\\\Exception\\\\DriverException\",\"Message\":\"An exception occurred while executing 'UPDATE \\\"oc_properties\\\" SET \\\"propertypath\\\" = ? WHERE \\\"userid\\\" = ? AND \\\"propertypath\\\" = ?' with params [\\\"files\\\\\\\LONG_FILENAME_REPLACED_WITH_247_CHARACTERS", \\\"LONG_FILENAME_REPLACED_WITH_247_CHARACTERS"]:\\n\\nSQLSTATE[22001]: String data, right truncated: **7 ERROR: value too long for type character varying(255)**\",\"Code\":0,\"Trace\":\"#0 \\\/opt\\\/nextcloud\\\/3rdparty\\\/doctrine\\\/dbal\\\/lib\\\/Doctrine\\\/DBAL\\\/DBALException.php(128): Doctrine\\\\DBAL\\\\Driver\\\\AbstractPostgreSQLDriver->convertException('An exception oc...', Object(Doctrine\\\\DBAL\\\\Driver\\\\PDOException))\\n#1 \\\/opt\\\/nextcloud\\\/3rdparty\\\/doctrine\\\/dbal\\\/lib\\\/Doctrine\\\/DBAL\\\/Statement.php(178): Doctrine\\\\DBAL\\\\DBALException::driverExceptionDuringQuery(Object(Doctrine\\\\DBAL\\\\Driver\\\\PDOPgSql\\\\Driver), Object(Doctrine\\\\DBAL\\\\Driver\\\\PDOException), 'UPDATE \\\"oc_prop...', Array)\\n#2 \\\/opt\\\/nextcloud\\\/apps\\\/dav\\\/lib\\\/DAV\\\/CustomPropertiesBackend.php(179): Doctrine\\\\DBAL\\\\Statement->execute(Array)\\n#3 \\\/opt\\\/nextcloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/PropertyStorage\\\/Plugin.php(147): OCA\\\\DAV\\\\DAV\\\\CustomPropertiesBackend->move('files\\\/87c48f84-...', 'files\\\/87c48f84-...')\\n#4 [internal function]: Sabre\\\\DAV\\\\PropertyStorage\\\\Plugin->afterMove('files\\\/87c48f84-...', 'files\\\/87c48f84-...')\\n#5 \\\/opt\\\/nextcloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#6 \\\/opt\\\/nextcloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(648): Sabre\\\\Event\\\\EventEmitter->emit('afterMove', Array)\\n#7 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpMove(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#8 \\\/opt\\\/nextcloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#9 \\\/opt\\\/nextcloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(479): Sabre\\\\Event\\\\EventEmitter->emit('method:MOVE', Array)\\n#10 \\\/opt\\\/nextcloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#11 \\\/opt\\\/nextcloud\\\/apps\\\/dav\\\/lib\\\/Server.php(258): Sabre\\\\DAV\\\\Server->exec()\\n#12 \\\/opt\\\/nextcloud\\\/apps\\\/dav\\\/appinfo\\\/v2\\\/remote.php(33): OCA\\\\DAV\\\\Server->exec()\\n#13 \\\/opt\\\/nextcloud\\\/remote.php(164): require_once('\\\/opt\\\/nextcloud\\\/...')\\n#14 {main}\",\"File\":\"\\\/opt\\\/nextcloud\\\/3rdparty\\\/doctrine\\\/dbal\\\/lib\\\/Doctrine\\\/DBAL\\\/Driver\\\/AbstractPostgreSQLDriver.php\",\"Line\":91}","userAgent":"Mozilla\/5.0 (Macintosh) mirall\/2.4.1 (build 9367)","version":"12.0.6.1"} ``` ### Expected behaviour I would like to - receive an error in the client during the initial sync of a file with a too long path, so that I can correct this on the client. - receive an sync error in the client when the move failed due to a too long filename - maybe a nice little helper routine that checks that local filenames are not exceeding the expected length. Upps, this depends on the Username in the server, the username can be long in scenarios with synced useraccounts ### Actual behaviour Files with too long paths are synced to the server and encounter problems on later move operations. It looks like the move is executed like a copy and the original file stays in the source directory. But this is not happening always. I assume that it depends on the resulting file path in the destination directory. ### Server configuration **Operating system**: ubuntu 14.04 LTS **Web server:** Apache 2.4 **Database:** postgresql 9.4 **PHP version:** php 5.6 **Nextcloud version:** (see Nextcloud admin page) see above, 12.0.6.1, (I updated the server to 13 afterwards, a few server configs below are from the new server, I try to reproduce this under 13.) **Updated from an older Nextcloud/ownCloud or fresh install:** Migration from owncloud 9 or 10. **Where did you install Nextcloud from:** **Signing status:** <details> <summary>Signing status</summary> No errors have been found. </details> **List of activated apps:** This is from the server after upgrade to v 13. Enabled: - activity: 2.6.1 - admin_audit: 1.3.0 - comments: 1.3.0 - dav: 1.4.7 - federatedfilesharing: 1.3.1 - federation: 1.3.0 - files: 1.8.0 - files_pdfviewer: 1.2.1 - files_sharing: 1.5.0 - files_texteditor: 2.5.1 - files_trashbin: 1.3.0 - files_versions: 1.6.0 - files_videoplayer: 1.2.0 - firstrunwizard: 2.2.1 - gallery: 18.0.0 - logreader: 2.0.0 - lookup_server_connector: 1.1.0 - nextcloud_announcements: 1.2.0 - notifications: 2.1.2 - oauth2: 1.1.1 - password_policy: 1.3.0 - provisioning_api: 1.3.0 - serverinfo: 1.3.0 - sharebymail: 1.3.0 - survey_client: 1.1.0 - systemtags: 1.3.0 - theming: 1.4.5 - twofactor_backupcodes: 1.2.3 - updatenotification: 1.3.0 - user_ldap: 1.3.1 - workflowengine: 1.3.0 Disabled: - bruteforcesettings - encryption - files_antivirus - files_external - user_external </details> **Nextcloud configuration:** <details> <summary>Config report</summary> { "system": { "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "***REMOVED SENSITIVE VALUE***", "***REMOVED SENSITIVE VALUE***" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***", "version": "13.0.4.0", "dbtype": "pgsql", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbname": "***REMOVED SENSITIVE VALUE***", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "dbtableprefix": "oc_", "logtimezone": "UTC", "installed": true, "ldapIgnoreNamingRules": false, "loglevel": 3, "log_type": "owncloud", "logfile": "\/opt\/oc-data\/nextcloud.log", "maintenance": false, "singleuser": false, "memcache.local": "\\OC\\Memcache\\Redis", "filelocking.enabled": "true", "memcache.distributed": "\\OC\\Memcache\\Redis", "memcache.locking": "\\OC\\Memcache\\Redis", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 6379, "timeout": 0, "dbindex": 0 }, "trashbin_retention_obligation": "auto, 60", "versions_retention_obligation": "auto", "theme": "", "updater.release.channel": "production", "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory", "updater.secret": "***REMOVED SENSITIVE VALUE***" } } </details> **Are you using external storage, if yes which one:** local/smb/sftp/... NO **Are you using encryption:** yes/no NO **Are you using an external user-backend, if yes which one:** LDAP/ActiveDirectory/Webdav/... YES, LDAP Apple OD, config not pasted, as not relevant. </details> ### Client configuration **Browser:** **Operating system:** MACOS, nextcloud client 2.3.3 ### Logs #### Web server error log not relevant #### Nextcloud log (data/nextcloud.log) see above #### Browser log not relevant </details>

github.com/nextcloud/server

failed to open stream: File name too long

opened 10:10PM - 24 Mar 17 UTC

nazar-pc

bug 1. to develop feature: filesystem 25-feedback 29-feedback hotspot: filename handling

### Steps to reproduce 1. Create file with name that is close to filesystem lim…it of 255 bytes (say 253 bytes) 2. Try to sync the file ### Expected behaviour File is synchronized correctly ### Actual behaviour File is not synchronized correctly because Nextcloud adds `.ocTransferId**********.part` suffix to the end of the file name and thus exceeds filesystem limit for the file name length. ### Additional details I've got this long file name by synchronization of directory that contains eCryptfs data. My local filesystem is btrfs, filesystem on server is ext4, both limited by 255 bytes for the filename. Using completely random controllable filenames during uploading will solve issues like this once and forever. ### Server configuration **Operating system**: Debian Jessie under Docker **Web server:** Nginx 1.11.10 **Database:** MariaDB 10.1.22 **PHP version:** 7.0.17 **Nextcloud version:** 11.0.2 **Updated from an older Nextcloud/ownCloud or fresh install:** Fresh install **Where did you install Nextcloud from:** https://github.com/nazar-pc/docker-webserver-apps/tree/master/nextcloud **Are you using external storage, if yes which one:** no **Are you using encryption:** no ### Logs #### Nextcloud log (data/nextcloud.log) <details> <summary>Nextcloud log</summary> ``` { "reqId" : "***", "remoteAddr" : "****", "app" : "PHP", "message" : "fopen(\/data\/nginx\/www\/data\/nazar\/files\/Nextcloud\/Encrypted\/ECRYPTFS_FNEK_ENCRYPTED.FWaZ3jSvM8HFIkYWHAexJ2WpOyhTopXGRhjBXNoIYclgjXbtIzBdPW1r8k--\/ECRYPTFS_FNEK_ENCRYPTED.FeaZ3jSvM8HFIkYWHAexJ2WpOyhTopXGRhjB38DwyoKD5SxcCU7QOetpI6bdC4EOd1t4q-voY-cm3NbMJ2sJEtsxmOvrVRdX1IdrLFx3J8LoIaSDFfhzfWsquuOO50JyIHM1MdNjfabjtgfLyVV1TQq-mzTV9MKUE8izTckfeMkVD.LjcKqy5s0A-FEVkxyosYAdqrxcmYoiFFgpf2amE6gmMW4J-mj6qG1x.ocTransferId1216630867.part): failed to open stream: File name too long at \/data\/nginx\/www\/lib\/private\/Files\/Storage\/Local.php#287", "level" : 3, "time" : "2017-03-24T19:28:36+00:00", "method" : "MOVE", "url" : "\/remote.php\/dav\/uploads\/nazar\/3759697667\/.file", "user" : "nazar", "version" : "11.0.2.7" } ``` </details>

I let you go through this, if there is a way to go around that. It must be more annoying for users on OS that don’t have this restricition.

And your backup, there is no way they use smaller file names? Just thinking, if you have a backup and you restore on a different computer that does not have the registry changes, this is always a bit complicated.

Hewal · November 30, 2024, 3:56pm

No unforntunatly there is no way to make the mails shorter. It’s a strange thing, because windows can handle it without the registry setting (restore does work).