Understanding the "No coreNodeName" Error After Upgrading to Solr 10

Upgrading Apache Solr from version 9.x to 10.0.0 is a major step. If you performed this upgrade using the install_solr_service.sh script and suddenly found that your standalone cores fail to load with errors like No coreNodeName for CoreDescriptor, you are not alone. This error indicates that your Solr instance is attempting to start in SolrCloud mode instead of standalone mode, even if you did not explicitly configure ZooKeeper in your solr.in.sh file.

In this guide, we will explore why Solr 10 defaults to cloud mode, how to verify which configuration variables control this behavior, and how to successfully restore your cores.

Why is Solr Running in Cloud Mode After the Upgrade?

In Apache Solr 9.x, standalone mode was officially deprecated. With the release of Solr 10.0.0, the community has pushed further toward a "Cloud-first" architecture. When you run the install_solr_service.sh script from the Solr 10 distribution, the newly generated service files and default configurations may default to starting Solr with the -c (cloud) flag enabled.

If Solr starts with the cloud flag active, it automatically spins up an embedded ZooKeeper instance (if no external ZK host is specified) and expects your cores to have cloud-specific metadata, such as a coreNodeName. Because your existing standalone cores lack this metadata, they fail to load, throwing the No coreNodeName for CoreDescriptor exception.

How to Identify and Control Standalone vs. Cloud Mode

Solr's operational mode is controlled by two main factors: startup command-line flags and environment variables. To find out why your server is starting in cloud mode, check the following configuration points:

1. Check the Systemd Service Unit File

Since you used the installation script, Solr is likely running as a systemd service. The service definition file often overrides your default configurations.

  • Open the Solr service file (typically located at /etc/systemd/system/solr.service or /lib/systemd/system/solr.service).
  • Look at the ExecStart directive. If it contains the -c or --cloud argument, Solr will start in SolrCloud mode regardless of your solr.in.sh settings.
# Example of a Cloud-mode ExecStart:
ExecStart=/opt/solr/bin/solr start -c -p 8983

# Example of a Standalone-mode ExecStart:
ExecStart=/opt/solr/bin/solr start -p 8983

2. Inspect the Correct solr.in.sh File

There are often multiple solr.in.sh files on a system after an upgrade. The installer script typically places the active configuration file in /etc/default/solr.in.sh or /var/solr/solr.in.sh, while leaving a template file in /opt/solr/bin/solr.in.sh.

Ensure you are editing the active file and check for the following environment variables:

  • SOLR_MODE: In newer Solr versions, this can be set to standalone or solrcloud.
  • SOLR_CLOUD: Setting this to false forces standalone mode.
# Force standalone mode in /etc/default/solr.in.sh
SOLR_MODE=standalone
# Or alternatively:
SOLR_CLOUD=false

How to Resolve the Issue

Depending on your long-term architecture plans, you have two ways to resolve this issue:

Option A: Force Solr Back into Standalone Mode (Quick Fix)

If you want to keep running your classic standalone setup, you must strip the cloud flags from your startup routine:

  1. Open /etc/default/solr.in.sh and ensure SOLR_MODE=standalone is defined.
  2. Edit your solr.service file to remove any -c or -cloud arguments from the ExecStart command.
  3. Reload the systemd daemon and restart the Solr service:
sudo systemctl daemon-reload
sudo systemctl restart solr

Option B: Migrate to Single-Node SolrCloud (Recommended)

Because standalone mode is deprecated, the recommended path for Solr 10 is to run a single-node SolrCloud cluster. This gives you the modern APIs and features of SolrCloud without requiring multiple servers.

To transition your standalone cores to SolrCloud:

  1. Keep Solr running in Cloud mode.
  2. Upload your core's configuration directory to the embedded ZooKeeper using the Solr CLI:
/opt/solr/bin/solr zk upconfig -n my_config -d /var/solr/data/428/conf -z localhost:9983
  1. Create a collection linking to this configuration:
curl "http://localhost:8983/solr/admin/collections?action=CREATE&name=428&numShards=1&replicationFactor=1&collection.configName=my_config"

This approach future-proofs your search infrastructure and ensures seamless upgrades for subsequent Solr versions.