[Bug]: Files with hash (#) character in filename cannot be downloaded, opened, or deleted

[HMZ0XB]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Files containing a hash (#) character in their filename cannot be downloaded, opened, or deleted through both the web interface and desktop sync client.

When attempting to download or open such files via the web UI, the request fails with a 400 Bad Request error. The files are visible in the file list but any interaction with them fails.

This affects:

• Download via web interface (400 Bad Request)
• Opening files in web interface (400 Bad Request)
• Deleting files from regular folders (fails silently or with error)
• Sync via desktop client (files not synced)

Example affected filenames:

• testfile#00001.pdf
• report#1.pdf
• file#test.txt

The hash character is interpreted as a URL fragment identifier instead of being properly encoded as %23, causing the server to receive a malformed request.

Note: Issue #41154 fixed deletion from trash, and issue nextcloud/text#218 fixed editing in text app, but the general download/open/delete problem persists in Nextcloud 32.0.3.

Steps to reproduce

1. Upload a file with a hash (#) character in the filename to Nextcloud (e.g., test#file.pdf)
2. Navigate to the file in the web interface
3. Attempt to download the file by clicking on it or using the download action
4. Observe: 400 Bad Request error occurs
5. Alternatively: Try to delete the file from the regular folder (not trash)
6. Observe: Deletion fails

WebDAV test:
Using curl to download via WebDAV also fails:

curl -u "user:pass" "https://server/remote.php/dav/files/user/folder/file%0001.pdf"
# Returns: HTTP 400 Bad Request

Expected behavior

Files with hash (#) characters in their filename should be properly URL-encoded (# → %23) and should be downloadable, openable, and deletable just like any other file.

The hash character should be treated as a regular filename character, not as a URL fragment identifier.

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.3

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 31 to 32)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "upgrade.disable-web": true,
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "********.***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "32.0.3.2",
        "overwrite.cli.url": "https:\/\/********.***",
        "overwriteprotocol": "https",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "default_phone_region": "DE",
        "maintenance_window_start": "1",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "1025",
        "maintenance": false,
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "loglevel": 2
    }
}

List of activated Apps

Enabled:
  - activity: 5.0.0-dev.0
  - app_api: 32.0.0
  - bruteforcesettings: 5.0.0-dev.0
  - circles: 32.0.0
  - cloud_federation_api: 1.16.0
  - comments: 1.22.0
  - contacts: 8.0.5
  - contactsinteraction: 1.13.1
  - dav: 1.34.2
  - federatedfilesharing: 1.22.0
  - federation: 1.22.0
  - files: 2.4.0
  - files_downloadlimit: 5.0.0-dev.0
  - files_pdfviewer: 5.0.0-dev.0
  - files_reminders: 1.5.0
  - files_sharing: 1.24.1
  - files_trashbin: 1.22.0
  - files_versions: 1.25.0
  - firstrunwizard: 5.0.0-dev.0
  - groupfolders: 20.1.2
  - logreader: 5.0.0-dev.0
  - lookup_server_connector: 1.20.0
  - notifications: 5.0.0-dev.0
  - oauth2: 1.20.0
  - photos: 5.0.0-dev.1
  - privacy: 4.0.0-dev.0
  - profile: 1.1.0
  - provisioning_api: 1.22.0
  - recommendations: 5.0.0-dev.0
  - related_resources: 3.0.0-dev.0
  - serverinfo: 4.0.0-dev.0
  - settings: 1.15.1
  - sharebymail: 1.22.0
  - sociallogin: 6.2.3
  - systemtags: 1.22.0
  - text: 6.0.1
  - theming: 2.7.0
  - twofactor_backupcodes: 1.21.0
  - updatenotification: 1.22.0
  - user_status: 1.12.0
  - viewer: 5.0.0-dev.0
  - webhook_listeners: 1.3.0
  - workflowengine: 2.14.0
Disabled:
  - admin_audit: 1.22.0
  - calendar: 6.0.2 (installed 6.0.2)
  - dashboard: 7.12.0 (installed 7.8.0)
  - encryption: 2.20.0
  - facerecognition: 0.9.70 (installed 0.9.70)
  - files_accesscontrol: 3.0.1 (installed 3.0.1)
  - files_external: 1.24.0
  - integration_deepl: 2.0.0 (installed 2.0.0)
  - nextcloud_announcements: 4.0.0-dev.0 (installed 1.17.0)
  - password_policy: 4.0.0-dev.0 (installed 1.18.0)
  - quota_warning: 1.22.0 (installed 1.22.0)
  - support: 4.0.0-dev.0 (installed 1.11.0)
  - survey_client: 4.0.0-dev.0 (installed 1.16.0)
  - suspicious_login: 10.0.0-dev.0
  - twofactor_nextcloud_notification: 6.0.0-dev.0
  - twofactor_totp: 14.0.0
  - user_ldap: 1.23.0
  - weather_status: 1.12.0 (installed 1.8.0)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Additional info

• Desktop client version: 3.16.7-1~deb13u1 (Qt 6.8.2)
• OS: Debian 13 (Trixie)
• The issue affects multiple file types (PDF, ODT, EML, etc.)
• Approximately 40+ files are affected in the user's directory
• Files were uploaded before a Nextcloud update (likely worked in older versions)
• Related issues: [Bug]: Error delete files with character # from trash bin #41154 (fixed deletion from trash), Files with hash in filename (#) can not be edited text#218 (fixed text editor)
• The problem persists in the web UI, WebDAV, and desktop sync client

[ZeroEcks]

Confirming after upgrading I am also affected, this is fairly bad because we have now lost access to folders without going into the backend to (hopefully) resolve this.