[Bug]: Oracle: user_ldap fails after upgrade due to quoted identifier case mismatch (OWNCLOUD_NAME vs owncloud_name)

[agtejeo]

⚠️ 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

After upgrading Nextcloud from 33.0.2 to 33.0.3 on Oracle Database 12.2, LDAP authentication stopped working due to a case mismatch in quoted Oracle identifiers used by the user_ldap app.

The issue appears to be caused by different code paths referencing the same columns using different quoted identifier casing:

"owncloud_name"

and

"OWNCLOUD_NAME"

In Oracle, quoted identifiers are case-sensitive, therefore these are treated as different column names.

Environment
Nextcloud version before upgrade: 33.0.2
Nextcloud version after upgrade: 33.0.3
Database: Oracle Database 12.2.0.1
App: user_ldap 1.24.0
LDAP backend: OpenLDAP

Problem description

After the upgrade, LDAP users were no longer able to log in.

The Nextcloud log contained errors similar to:

ORA-00904: "OWNCLOUD_NAME": invalid identifier

The affected tables were:

oc_ldap_user_mapping
oc_ldap_group_mapping

The original table structure contained lowercase quoted column names:

ldap_dn
owncloud_name
directory_uuid
ldap_dn_hash

Some code paths appeared to query:

"OWNCLOUD_NAME"

while others queried:

"owncloud_name"

After renaming the columns to uppercase to satisfy one query path, other operations started failing with:

ORA-00904: "owncloud_name": invalid identifier

This suggests that different parts of the application are generating SQL with different quoted identifier casing.

Verification

LDAP itself continued to work correctly.

The following commands succeeded:

sudo -u apache php occ ldap:search user@domain
sudo -u apache php occ ldap:test-user-settings

The failure only occurred when accessing the application through the normal login flow.

Workaround applied

As a temporary workaround, duplicate uppercase and lowercase versions of the affected columns were created in both mapping tables.

Oracle triggers were added to keep both versions synchronized.

After applying this workaround:

LDAP login started working again.
ldap:test-user-settings worked correctly.
Normal user authentication was restored.
Expected behavior

The application should consistently use the same identifier casing when generating Oracle SQL queries, or avoid quoted identifier case mismatches altogether.

Additional notes

This issue appeared immediately after upgrading from 33.0.2 to 33.0.3 and was fully reproducible in our environment.

I would be happy to provide additional logs, table definitions, migration details, and the exact Oracle workaround if needed.

Steps to reproduce

Steps to reproduce

1. Install Nextcloud 33.0.2 using Oracle Database 12.2 as backend.

2. Configure and enable the user_ldap application.

3. Use the default LDAP mapping tables created by Nextcloud:

   • oc_ldap_user_mapping
   • oc_ldap_group_mapping

4. Verify that LDAP authentication works correctly.

5. Upgrade Nextcloud from 33.0.2 to 33.0.3 using the official updater.

6. Run:

sudo -u apache php occ upgrade

7. Attempt to authenticate using an LDAP user account.

Actual result

LDAP authentication fails.

Nextcloud logs show Oracle errors similar to:

ORA-00904: "OWNCLOUD_NAME": invalid identifier

or

ORA-00904: "owncloud_name": invalid identifier

depending on the state of the mapping tables.

The issue appears to be caused by different code paths referencing the same columns with different quoted identifier casing.

Database schema before upgrade

oc_ldap_user_mapping

ldap_dn
owncloud_name
directory_uuid
ldap_dn_hash

oc_ldap_group_mapping

owncloud_name
ldap_dn
directory_uuid
ldap_dn_hash

Expected result

LDAP authentication should continue to work after the upgrade.

The application should consistently reference the same column names when generating Oracle SQL statements and should not depend on different quoted identifier casing.

Expected behavior

The upgrade from Nextcloud 33.0.2 to 33.0.3 should complete without breaking LDAP authentication on Oracle.

Existing LDAP users should be able to continue logging in after the upgrade without requiring any manual database modifications.

The user_ldap app should use a consistent column naming strategy when generating Oracle SQL queries, avoiding failures caused by quoted identifier case mismatches (for example "owncloud_name" vs "OWNCLOUD_NAME").

No manual schema changes, column duplication, or Oracle triggers should be required to restore LDAP functionality after the upgrade.

Nextcloud Server version

33

Operating system

RHEL/CentOS

PHP engine version

PHP 8.4

Web server

Apache (supported)

Database engine version

Oracle

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

Updated from a MINOR version (ex. 32.0.1 to 32.0.2)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

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

Configuration report

# sudo -u apache php occ config:list system
{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "version": "33.0.3.2",
        "installed": true,
        "maintenance": false,
        "trusted_domains": [
            "myserver.domain.es",
            "server1.domain.es",
            "server2.domain.es"
        ],
        "overwrite.cli.url": "https:\/\/myserver.domain.es",
        "overwritehost": "myserver.domain.es",
        "overwriteprotocol": "https",
        "htaccess.RewriteBase": "\/",
        "overwritewebroot": "\/",
        "forcessl": true,
        "dbtype": "oci",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "dbtablespace": "USERS",
        "db_transaction_isolation_level": 2,
        "db.allow_readonly_transactions": true,
        "logtimezone": "Europe\/Madrid",
        "loglevel": 0,
        "log_type": "file",
        "logfile": "\/var\/log\/nextcloud.log",
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "ssl",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_smtpport": "465",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "timeout": 0,
            "password": "***REMOVED SENSITIVE VALUE***"
        },
        "filelocking.enabled": true,
        "filelocking.ttl": 3600,
        "maintenance_window_start": 2,
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/nextcloud\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/nextcloud\/apps-external",
                "url": "\/apps-external",
                "writable": true
            }
        ],
        "operation.mode": "clustered-instance",
        "default_phone_region": "ES",
        "integrity.ignore.missing.app.signature": [
            "theme-ugr2023"
        ],
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "theme": "ugr",
        "defaultapp": "files"
    }
}

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response