This page covers common errors you may encounter in cluster logs, client logs, or command output when using Alibaba Cloud Elasticsearch.
Jump to: 413 Request Entity Too Large · forbids automatic creation of the index · all shards failed · SSL/TLS errors · No keyword/multi-field defined · path is not accessible on master node · kibana did not load properly · unsupported_operation_exception · NoNodeAvailableException · Unclosed object / ArrayIndexOutOfBoundsException · No field found for metaData · API keys not enabled
413 Request Entity Too Large
A single bulk write request exceeds the http.max_content_length limit, which defaults to 100 MB. Do not change this limit.
Data written per request equals the number of documents multiplied by the average document size. Because document size varies, start tuning at 5 MB per request and work up to a maximum of 15 MB. For guidance, see Using and Sizing Bulk Requests and HTTP settings.
"forbids automatic creation of the index"
Auto Indexing is disabled on the cluster. Enable it in the Elasticsearch console:
-
Static method (recommended): Enable Auto Indexing in the YML File Configuration panel. For steps, see Configure the YML file.
-
Dynamic method: Run the corresponding API command to enable Auto Indexing without restarting the cluster.
"all shards failed"
This error appears when the cluster cannot serve queries from one or more shards. Common causes include node disconnection, shards still recovering after a restart, or a damaged disk.
Step 1: Diagnose
Check the cluster's monitoring data and logs to identify the root cause — for example, insufficient disk space or misconfigured index or cluster settings that block shard allocation.
Step 2: Fix unassigned shards
If node disconnection or unassigned shards are the cause:
-
Check the shard allocation status:
If all shards are already allocated, this command returns an error — that is expected behavior.
GET /_cluster/allocation/explain -
Retry failed shard allocation:
POST /_cluster/reroute?retry_failed=true
SSL/TLS errors in cluster logs
The cluster logs show an SSL/TLS error similar to the following when plaintext traffic is sent over an SSL connection. This typically happens when a node without encrypted communication tries to connect to a node that has encryption enabled.
Check the following:
-
HTTP vs. HTTPS mismatch: If HTTPS is not enabled on the cluster, access is only available over HTTP. Accessing the cluster over HTTPS triggers this error. To enable HTTPS, see Enable HTTPS.
-
IP address not allowlisted: Verify that the IP address shown in the cluster logs is in the public IP address whitelist. Add only the specific IP addresses or CIDR blocks you need — do not add
0.0.0.0/0.
For more SSL/TLS error patterns, see Common SSL/TLS exceptions.
"No keyword/multi-field defined exact matches for [KeywordField]"
This error occurs when you use the LIKE operator in an X-Pack SQL plug-in query against a text type field. The LIKE operator only supports exact filtering on keyword type fields. Switch the query to use a keyword field instead.
For background, see Unable to run SQL query on multi fields using Elastic Search v. 7.3 and SQL and multi-fields.
"path is not accessible on master node"
This error occurs when running PUT _snapshot/my_backup if the target Object Storage Service (OSS) bucket uses the Archive storage class. Archive buckets require object restoration before data can be read, which is incompatible with Elasticsearch snapshot operations.
Use a Standard storage class OSS bucket in the same region as the Elasticsearch cluster. For steps, see Create manual snapshots and restore data from manual snapshots.
"kibana did not load properly"
When disk usage on a data node exceeds 95%, Elasticsearch triggers write protection and sets read_only_allow_delete on all indexes. Writes are blocked; only reads and deletes are allowed.
Step 1: Resolve high disk usage (root cause)
Address the underlying disk usage first. See High disk usage and read-only indexes for options such as expanding disk capacity, deleting unused indexes, or configuring index lifecycle management.
Step 2: Restore write access
After resolving disk usage, reset the read-only flag across all indexes:
PUT _settings
{
"index.blocks.read_only_allow_delete": null
}
"unsupported_operation_exception" (aliyun-qos plug-in)
After enabling throttling with apack.qos.ratelimit.enabled, you see this error when configuring a limiter:
{
"error": {
"root_cause": [
{
"type": "unsupported_operation_exception",
"reason": "unsupported_operation_exception: only define search or bulk action for limit"
}
],
"type": "unsupported_operation_exception",
"reason": "unsupported_operation_exception: only define search or bulk action for limit"
},
"status": 500
}
The aliyun-qos plug-in is not at the latest version. Run GET /_cat/plugins?v to check the current version. The expected latest versions are:
-
Elasticsearch V7.10:
7.10.0_ali1.6.0.2 -
All other versions:
<ES version>-rc4
Upgrade based on your cluster version:
-
V7.10 clusters: Upgrade the kernel to V1.6.0. See Upgrade the version of a cluster.
-
Other versions: Submit a ticket to have Elasticsearch technical engineers upgrade the plug-in. Restart the cluster after the upgrade for the change to take effect.
-
Plug-in versions earlier than rc4 trigger this error.
-
You can upgrade the aliyun-qos plug-in on clusters running V6.7.0 or later. For clusters running earlier versions, upgrade the cluster to V6.7.0 or later first.
"NoNodeAvailableException" (Transport Client, port 9300)
When using Transport Client 5.5 or 5.6 to connect over port 9300, you may see:
NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{HVdK7Cff****_P0c9n****}{es-cn-v1qqweee****.elasticsearch.aliyuncs.com}{172.17.XX.XX:9300}]]
The 172.17.XX.XX IP address is not an actual node in the cluster — this is a known issue with those client versions. Use Transport Client 5.3.3 instead. See Transport Client (5.x).
"Unclosed object or array found" / "ArrayIndexOutOfBoundsException" (V7.4)
These errors are caused by bugs in open source Elasticsearch 7.4 and do not affect your business operations. The bugs are fixed in versions later than 7.4.
Alibaba Cloud Elasticsearch V7.4 is phased out. Purchase a cluster running a later version. If you need to migrate data before switching, see Select a data migration solution to choose the right approach for your workload.
"No field found for [metaData] in mapping with types" (aliyun-knn)
This error appears when using the aliyun-knn plug-in for vector search on an index configured with the cosine distance measurement function. Check the following:
-
Cluster version: The aliyun-knn plug-in requires Elasticsearch V6.7 with kernel V1.2 or later, or Elasticsearch V7.10 with kernel V1.4 or later. See Use the aliyun-knn plug-in for version requirements.
-
Script query method: Script queries must use the
script_scoreparameter. -
Field nesting: Verify that the fields specified in the query match the nesting structure of the index mapping. If the index uses nested fields, the query must reference nested fields accordingly.
"API keys not enabled in Elasticsearch"
The cluster does not have API key authentication enabled. API keys require HTTPS to be active on the cluster. Enable HTTPS to resolve this. See Enable HTTPS.