[SOLVED] Full Text Search Not Working in Browser or Android Client

Issue: Full Text Search dropdown does not appear when clicking the magnifier from the upper right hand corner of a browser and if the “Navigation Icon” for global search is active, the form for Full Text Search appears, but is unresponsive:

The following console command presents significant correctly indexed content:
curl -XGET ‘localhost:9200/nt_index/_search?q=health’

Magnifier search will present files containing the search expression.

Full Text Search Settings:

Environment:
CentOS 7.6.1810 Updated
php version 7.3.6
nginx 1.17.0
Nextcloud 16.0.1
Full Text Search 1.3.4 (installed from admin console)
Full Text Search - Files 1.3.2 (installed from admin console)
Full Text Search - Elasticsearch 1.3.4 (installed from admin console)
OpenJDK Runtime Environment (build 1.8.0_212-b04)
ElasticSearch 7.2.0

First index executed successfully. “Live” worker process successfully running.
Have not installed ReadonlyREST Elasticsearch Plugin at the current stage of testing. Concluded it would be better to add that feature upon verifying the base search functionality is working.

Several hours of google and forum searching hasn’t provided any clues.

Any suggestions???

SOLVED - It appears the “first index” had not been completed when attempting to test this functionality. Unfamiliar with ELASTICSEARCH in the NEXTCLOUD context, we were inadvertently interrupting the first indexing process, which was extensive since external storage shares had been previously established presenting a rather large list of files to process.

Having a limited context of files when deploying “Full Text Search” will promote a more responsive experience. If that is not possible, patience is your next best friend. Ensure your “first index” is complete. We were following various guides found on the internet that recommended executing the “first index” from the command prompt as follows: …occ fulltextsearch:index. For us, this resulted in console messages showing progress. There are times when that progress will appear frozen and potentially lead one to believe it is complete; waiting for new items to process. If it doesn’t return to the command prompt of the terminal, it has not completed its process; give it more time.

Hi very good answer but in my case after a while (one day) it freeze so I restart indexing again and again same problem. Can you give me a tip ?
Thank you.

Not knowing details of your circumstances and not being more experienced with these specific applications, I can only suggest, if you haven’t done so already, to complete the configuration and “first indexing” process with a limited document data set (just a few documents) via the desired connection type (in our case, windows share to a NAS). Using the command line “first indexing” approach previously mentioned in our originating post should provide helpful feedback to see if it is advancing through your document data set. If your index continues to freeze, focusing on platform configuration and resources may be helpful. Do you have a “permissions” or “access” issue? Do you have a RAM memory deficiency for your configuration? Do you have enough storage space to process and store the indexes? Do you have enough CPU resources to complete the job? etc. If those issues don’t resolve your problem, can you begin to swap out pieces or all of your configuration to alternate resources to rule out hardware, software and setup concerns?

While our indexer is up and running, we have noted it doesn’t seem to identify new documents saved to the external windows shares after the “first index” has completed. Subsequently, we put this effort on a back burner in lieu of high priority concerns, but expect to revisit this issue in the near future as there have been a number of version updates since we first deployed our indexer and we hope the additional time may have allowed google to collect more information on the topic as that, the lack of information, has been the big handicap.

Best of luck to you!