Support intro
Sorry to hear you’re facing problems. 
The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.
If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.
Getting help
In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.
Before clicking submit: Please check if your query is already addressed via the following resources:
- Official documentation (searchable and regularly updated)
- How to topics and FAQs
- Forum search
(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).
Hi everyone,
after migrating a Nextcloud AIO instance to a new platform, I’m running into an issue with fulltext search that I haven’t been able to resolve so far. I’m posting here in the hope that others might have seen something similar or can help spot what I might be missing.
Context / background
The instance was migrated from another platform (ARM64 to x86_64) using a Borg backup (data and database).
Since the Elasticsearch index is not part of the backup, a complete re-indexing of fulltext search was required after the migration.
Current setup
Nextcloud AIO 12.4.0
Nextcloud 32.0.3
Apps:
fulltextsearch 32.0.0
fulltextsearch_elasticsearch 32.0.2
Elasticsearch 8.19.9 (also tested 8.19.8 and 8.19.10)
Single-node Elasticsearch (AIO default)
Observed problem
Search works for filenames and basic metadata.
Many PDFs (including large books) are present in the Elasticsearch index, but their content is not searchable.
During productive indexing runs (php occ fulltextsearch:index), bulk indexing often ends with a ClientResponseException “unknown error”.
Some single-document indexing attempts work, but bulk indexing reproducibly shows problems.
What I have checked so far
Database and file cache are clean (files:scan, files:repair-tree, no orphaned entries).
Elasticsearch shows only one active index.
Index settings and mappings look consistent.
The ingest-attachment plugin is installed.
An attachment ingest pipeline exists.
Documents are written to the index and updated, but for many PDFs the indexed content field is empty.
No object storage is used; files are stored locally.
What makes this confusing
fulltextsearch:check and fulltextsearch:test both report OK, but they don’t seem to exercise the same bulk plus attachment indexing path as a real reindex.
A full reindex works in other environments, but I can’t reproduce that behavior here.
Current assumption (as a hypothesis)
At this point it looks less like a migration or configuration issue and more like a problem in the bulk plus attachment indexing path with the current fulltextsearch_elasticsearch and Elasticsearch version combination.
Before going further, I’d like to check whether others have seen similar behavior after migrations or with NC 32 and ES 8.19.x.
Any hints, confirmations, or ideas are very welcome.
Thanks!