nextcloud / server

☁️ Nextcloud server, a safe home for all your data
https://nextcloud.com
GNU Affero General Public License v3.0
26.76k stars 4k forks source link

[Bug]: Files search provider does not reply to any queries #39550

Open mdevl opened 1 year ago

mdevl commented 1 year ago

⚠️ This issue respects the following points: ⚠️

Bug description

The unified search is broken for files and does not return any results. Using the search functionality of Nextcloud within the Webgui, results are only obtained for anything that is not a file. Issuing a GET operation on ocs/v2.php/search/providers we can verify that the suitable provider is registered

      {
        "id": "files",
        "name": "Files",
        "order": "5",
        "#text": "..."
      }

If issuing a manual GET request along the lines

`ocs/v2.php/search/providers/files/search?term=my_test_file...`

Nothing happens, and no reply is received. In contrast, for e.g. ocs/v2.php/search/providers/contacts/search? replies are received as expected.

Correspondingly, when searching for files in the Webgui, the search simply remains stuck on waiting forever.

Steps to reproduce

  1. Navigate to the Nextcloud webgui
  2. Search for a known, existing file within the own folder
  3. No results are returned, and search remains perpetually waiting.

Expected behavior

File search should return a reply to get GET request and provide list of matching files.

Installation method

Community Docker image

Nextcloud Server version

25

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

MariaDB

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

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "overwriteprotocol": "https",
        "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "25.0.8.2",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "mail_smtpsecure": "tls",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "default_phone_region": "DE",
        "maintenance": false,
        "twofactor_enforced": "true",
        "twofactor_enforced_groups": [],
        "twofactor_enforced_excluded_groups": [],
        "theme": "",
        "loglevel": 2
    }
}

List of activated Apps

Enabled:
  - activity: 2.17.0
  - cfg_share_links: 4.1.0
  - circles: 25.0.0
  - cloud_federation_api: 1.8.0
  - comments: 1.15.0
  - contactsinteraction: 1.6.0
  - dashboard: 7.5.0
  - dav: 1.24.0
  - drawio: 2.1.1
  - federatedfilesharing: 1.15.0
  - federation: 1.15.0
  - files: 1.20.1
  - files_external: 1.17.0
  - files_markdown: 2.4.1
  - files_pdfviewer: 2.6.0
  - files_rightclick: 1.4.0
  - files_sharing: 1.17.0
  - files_trashbin: 1.15.0
  - files_versions: 1.18.0
  - firstrunwizard: 2.14.0
  - geoblocker: 0.5.11
  - groupfolders: 13.1.3
  - logreader: 2.10.0
  - lookup_server_connector: 1.13.0
  - nextcloud_announcements: 1.14.0
  - notifications: 2.13.1
  - oauth2: 1.13.1
  - password_policy: 1.15.0
  - photos: 2.0.1
  - privacy: 1.9.0
  - provisioning_api: 1.15.0
  - ransomware_protection: 1.14.0
  - recommendations: 1.4.0
  - related_resources: 1.0.4
  - serverinfo: 1.15.0
  - settings: 1.7.0
  - sharebymail: 1.15.0
  - support: 1.8.0
  - survey_client: 1.13.0
  - systemtags: 1.15.0
  - text: 3.6.0
  - theming: 2.0.1
  - twofactor_backupcodes: 1.14.0
  - twofactor_webauthn: 1.2.0
  - updatenotification: 1.15.0
  - user_status: 1.5.0
  - viewer: 1.9.0
  - weather_status: 1.5.0
  - workflowengine: 2.7.0
Disabled:
  - admin_audit
  - bruteforcesettings
  - encryption
  - sharepermissions
  - suspicious_login
  - twofactor_totp
  - user_ldap

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

The Nextcloud logs contain sensitive information, with the failed search queries making no appearance (to the best of my judgment). Hence omitted. I.e., search queries for files are simply swallowed without any appearance in the log.

Additional info

Using primary and secondary DB, running behind a traefik proxy.

joshtrichards commented 1 year ago

Hi @mdevl - Thanks for the report. I'm unable to reproduce this, unfortunately.

Any chance you just have "Search for X only" clicked in the 3-dots menu to the right of the search input box? (Just checking the obvious to rule things out - no judgement if so!)

In your browser console, when you trigger a search you should see a bunch of simultaneous queries to /ocs/v2.php/search/providers/[numerous]/search?term=blah sent off to all the various providers. In that bunch, does the one that goes to /ocs/v2.php/search/providers/files/search have a return code? (I suppose not if you're just seeing the front-end wait forever...)

Anything special about the files you're searching for? e.g.

Does it matter which application you are currently within in the web ui when reproducing this behavior? (i.e. Files vs Contacts vs Calendar vs Talk)

The Nextcloud logs contain sensitive information, with the failed search queries making no appearance (to the best of my judgment). Hence omitted. I.e., search queries for files are simply swallowed without any appearance in the log.

Any searches that generate exceptions on the back-end should be showing up.

The individual queries to each provider should show also be in your web server logs (both successful and otherwise). I'd be interested in the return codes there.

Using primary and secondary DB, running behind a traefik proxy.

Multi-master?

mdevl commented 1 year ago

Thanks @joshtrichards for taking a look at the issue.

Neither in the browser nor the native Nextcloud app (NC25) does there seem to be any obvious way (to me) to filter down the search queries. Is this a newer feature introduced, or is there some misunderstanding here? That being said, it will not be the cause of this issue: I manually executed a GET request on the appropriate API endpoint to search for files on the Nextcloud server and received no reply.

If you trigger a search query and look at the logs, files is the only provider that does not make an appearance in the log at all. Here are the log entries that resulted from searching for my_test_file:

nextcloud-app    | 192.168.48.2 - - [11/Apr/2023:13:17:07 +0000] "GET /ocs/v2.php/search/providers/calendar/search?term=my_test_file&from=%2Fapps%2Ffiles%2F%3Fdir%3D%2Fpersonal%26fileid%3D52966391 HTTP/1.1" 200 886 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
nextcloud-app    | 192.168.48.2 - - [11/Apr/2023:13:17:07 +0000] "GET /ocs/v2.php/search/providers/comments/search?term=my_test_file&from=%2Fapps%2Ffiles%2F%3Fdir%3D%2Fpersonal%26fileid%3D52966391 HTTP/1.1" 200 886 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
nextcloud-app    | 192.168.48.2 - - [11/Apr/2023:13:17:07 +0000] "GET /ocs/v2.php/search/providers/tasks/search?term=my_test_file&from=%2Fapps%2Ffiles%2F%3Fdir%3D%2Fpersonal%26fileid%3D52966391 HTTP/1.1" 200 886 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
nextcloud-app    | 192.168.48.2 - - [11/Apr/2023:13:17:07 +0000] "GET /ocs/v2.php/search/providers/circles/search?term=my_test_file&from=%2Fapps%2Ffiles%2F%3Fdir%3D%2Fpersonal%26fileid%3D52966391 HTTP/1.1" 200 884 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
nextcloud-app    | 192.168.48.2 - - [11/Apr/2023:13:17:07 +0000] "GET /ocs/v2.php/search/providers/settings_apps/search?term=my_test_file&from=%2Fapps%2Ffiles%2F%3Fdir%3D%2Fpersonal%26fileid%3D52966391 HTTP/1.1" 200 885 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
nextcloud-app    | 192.168.48.2 - - [11/Apr/2023:13:17:07 +0000] "GET /ocs/v2.php/search/providers/settings/search?term=my_test_file&from=%2Fapps%2Ffiles%2F%3Fdir%3D%2Fpersonal%26fileid%3D52966391 HTTP/1.1" 200 887 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
nextcloud-app    | 192.168.48.2 - - [11/Apr/2023:13:17:07 +0000] "GET /ocs/v2.php/search/providers/contacts/search?term=my_test_file&from=%2Fapps%2Ffiles%2F%3Fdir%3D%2Fpersonal%26fileid%3D52966391 HTTP/1.1" 200 887 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"

Hence it is also irrelevant where the files are located since the files search provider as a whole fails entirely, irrespective of everything else (searching from the webgui or native app).

I Issued a GET .../ocs/v2.php/search/providers in order to verify that the files search provider was registered

{
  "meta": {
    "status": "ok",
    "statuscode": "200",
    "message": "OK",
    "#text": "..."
  },
  "data": {
    "element": [
      {
        "id": "settings_apps",
        "name": "Apps",
        "order": "-50",
        "#text": "..."
      },
      {
        "id": "files",
        "name": "Files",
        "order": "5",
        "#text": "..."
      },
      # (shortened/removed remaining entries)
    ],
    "#text": "..."
  },
  "#text": "..."
}

and then - as mentioned above - also triggered a manual search for files via a GET on the /ocs/v2.php/search/providers/files endpoint. For e.g. contacts I received a reply as expected. For files, no reply is returned at all.

As such, regarding your interest in seeing the return code or the exceptions associated with the files search queries in the log: both are unfortunately not applicable, as no returns or log entries exist assciated with files ever come into being. The GET query associated with the file searches is unfortunately just swallowed up completely without ever returning anything, raising an error, or logging anything. Everything disappearing in a black void completely unfortunately makes it sort of difficult to troubleshoot.

Regarding the DBs: The DBs are setup as master-slave for the purpose of backups.