Server: 404 for user home folder after upgrade from 19.0.3 to >=19.0.4 & 20

Created on 9 Oct 2020  路  8Comments  路  Source: nextcloud/server

Steps to reproduce

  1. Upgrade from 19.03 to 19.04 using web updater
  2. Log in to nextcloud or use the nextcloud desktop app

Expected behaviour

After logging in I expect to see all my files respective the Nextcloud Desktop app to synchronize all files.

Actual behaviour

After logging in I see an empty file list and Nextcloud Desktop says "404 folder does not exist"

Maybe this is related to my username which is for historic reasons "name+extension@domain".

Server configuration

Operating system: Debian Buster

Web server: Apache 2.4

Database: 10.3.23-MariaDB-0+deb10u1-log

PHP version: PHP 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72

Nextcloud version: (see Nextcloud admin page) 19.0.4

Updated from an older Nextcloud/ownCloud or fresh install: Updated from 19.0.3

Signing status:


Signing status

No errors have been found.

List of activated apps:


App list

Enabled:
  - accessibility: 1.5.0
  - activity: 2.12.1
  - calendar: 2.0.4
  - cloud_federation_api: 1.2.0
  - comments: 1.9.0
  - contacts: 3.4.0
  - contactsinteraction: 1.0.0
  - dav: 1.15.0
  - deck: 1.1.0
  - federatedfilesharing: 1.9.0
  - federation: 1.9.0
  - files: 1.14.0
  - files_external: 1.10.0
  - files_pdfviewer: 1.8.0
  - files_rightclick: 0.16.0
  - files_sharing: 1.11.0
  - files_trashbin: 1.9.0
  - files_versions: 1.12.0
  - files_videoplayer: 1.8.0
  - firstrunwizard: 2.8.0
  - gpxpod: 4.2.2
  - impersonate: 1.6.1
  - logreader: 2.4.0
  - lookup_server_connector: 1.7.0
  - nextcloud_announcements: 1.8.0
  - notifications: 2.7.0
  - oauth2: 1.7.0
  - photos: 1.1.0
  - polls: 1.5.4
  - provisioning_api: 1.9.0
  - richdocuments: 3.7.4
  - serverinfo: 1.9.0
  - settings: 1.1.0
  - sharebymail: 1.9.0
  - spreed: 9.0.4
  - systemtags: 1.9.0
  - tasks: 0.13.3
  - text: 3.0.1
  - theming: 1.10.0
  - twofactor_backupcodes: 1.8.0
  - updatenotification: 1.9.0
  - viewer: 1.3.0
  - workflowengine: 2.1.0
Disabled:
  - admin_audit
  - encryption
  - password_policy
  - privacy
  - recommendations
  - support
  - survey_client
  - user_ldap

Nextcloud configuration:


Config report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "19.0.4.2",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "forcessl": true,
        "loglevel": 2,
        "integrity.check.disabled": false,
        "apps_paths": [
            {
                "path": "\/var\/www\/XXX\/apps",
                "url": "\/apps",
                "writable": true
            }
        ],
        "maintenance": false,
        "theme": "",
        "overwrite.cli.url": "https:\/\/XXX",
        "overwriteprotocol": "https",
        "activity_expire_days": 31,
        "trusted_domains": [
            "XXX"
        ],
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trashbin_retention_obligation": "auto",
        "htaccess.RewriteBase": "\/",
        "mail_smtpmode": "sendmail",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "appstore.experimental.enabled": false,
        "singleuser": false,
        "log_rotate_size": 104857600,
        "logtimezone": "Europe\/Berlin",
        "mail_sendmailmode": "pipe",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "filelocking.enabled": true,
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0
        },
        "mysql.utf8mb4": true,
        "updater.release.channel": "stable",
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: Firefox 81.0.1

Operating system: Win10

Logs

Web server error log


Web server error log

XXX - - [09/Oct/2020:15:50:26 +0200] "PROPFIND /remote.php/dav/files/name+extension@domain/ HTTP/1.1" 404 1075 "-" "Mozilla/5.0 (Windows) mirall/2.6.5stable-Win64 (build 20200710) (Nextcloud)"
XXX - - [09/Oct/2020:15:50:43 +0200] "PROPFIND /remote.php/dav/files/name+extension@domain/ HTTP/2.0" 404 585 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"

Nextcloud log (data/nextcloud.log)


Nextcloud log

No related log entries.

1. to develop bug dav high regression

All 8 comments

Downgrading to 19.0.3 solved the issue.

Maybe this is related to my username which is for historic reasons "name+extension@domain".

Sounds like https://github.com/nextcloud/server/pull/22770.

cc @nextcloud/server-triage :wave:

Maybe related: In 19.0.3 the trash is display as empty for that user, however, the name+extension@domain/files_trashbin/files/ folder contains several files (also a ./occ files:scan -- name+extension@domain did not help).

@MorrisJobke @nickvergessen @blizzz

Maybe related: In 19.0.3 the trash is display as empty for that user, however, the name+extension@domain/files_trashbin/files/ folder contains several files (also a ./occ files:scan -- name+extension@domain did not help).

After further debugging: This is indeed unrelated. Firefox shows me a XML processing error (caused by a filename which is not proper UTF-8: 'Moroza Knozova'$'\357\277\277'' - Rosolam (Novomix).mp3.d1602168769' in bash). Should in this case an error shown to the user instead of "there are not deleted files"?

For now affected instances can revert https://github.com/nextcloud/server/pull/22770/files locally.

Since + can not be used it should be the exception here. So maybe we can add it as a fall back when we didn't find the user with urldecode() we try without?

This issue is still in 19.0.5, requiring affected people to update and then patch their installation manually.

I don't think that such unsystematic/random encodings/decodings should be done at all.

Was this page helpful?
0 / 5 - 0 ratings