# Recovering from cluster.blocks.read\_only=true in dynamic settings

**URL:** <https://discuss.elastic.co/t/recovering-from-cluster-blocks-read-only-true-in-dynamic-settings/27050>\
**Category:** Elasticsearch\
**Created:** [August 7, 2015, 2:01pm UTC](https://discuss.elastic.co/t/recovering-from-cluster-blocks-read-only-true-in-dynamic-settings/27050 "2015-08-07T14:01:21Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![magnusbaeck](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/magnusbaeck/32/44943_2.png) [@magnusbaeck](https://discuss.elastic.co/u/magnusbaeck)\
**Post date:** [August 7, 2015, 2:01pm UTC](https://discuss.elastic.co/t/recovering-from-cluster-blocks-read-only-true-in-dynamic-settings/27050/1 "2015-08-07T14:01:21Z")

</div>

I managed to get cluster.blocks.read\_only=true into my persistent dynamic settings. Unfortunately, when the cluster is read only it doesn't seem to allow changes in the dynamic settings so I can't figure out how to get out of this situation.

```
$ cat /tmp/dynamic-settings.json
{
    "transient": {
        "cluster.blocks.read_only": "false"
    },
    "persistent": {
        "cluster.blocks.read_only": "false"
    }
}
$ curl -XPUT localhost:9200/_cluster/settings?pretty -d @- < /tmp/dynamic-settings.json
{
  "error" : "RemoteTransportException[[seldlx3178][inet[/10.128.247.145:9300]][cluster:admin/settings/update]]; nested: ClusterBlockException[blocked by: [FORBIDDEN/6/cluster read-only (api)];]; ",
  "status" : 403
}

```

I'm able to set read\_only=false as a transient setting only (like above but with the persistent setting omitted) so that I end up with read\_only=false as a transient setting but read\_only=true remains as a persistent setting and seems to take precedence.

This is on a test cluster so it's okay to e.g. lose some state or do a full cluster restart but it would be nice to keep the data in the indexes. Help? I'm running Elasticsearch 1.7.1.

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [August 8, 2015, 12:58am UTC](https://discuss.elastic.co/t/recovering-from-cluster-blocks-read-only-true-in-dynamic-settings/27050/2 "2015-08-08T00:58:14Z")

</div>

I think you'll need an entire restart to get around this one ☹

---

<div class="post-metadata">

**Author:** ![magnusbaeck](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/magnusbaeck/32/44943_2.png) [@magnusbaeck](https://discuss.elastic.co/u/magnusbaeck)\
**Post date:** [August 10, 2015, 6:34am UTC](https://discuss.elastic.co/t/recovering-from-cluster-blocks-read-only-true-in-dynamic-settings/27050/3 "2015-08-10T06:34:59Z")

</div>

Huh. A full cluster restart actually _did_ help, which I find surprising since the problematic cluster.blocks.read\_only setting was set as a persistent setting.

But it seems it only worked when just setting the persistent setting in a request. When setting the persistent and transient settings in the same request (as in the original post above) after the restart I still got the complaint about the cluster being read-only. When gathering a shell transcript as evidence for a bug report a few minutes later it worked:

```
$ curl -XPUT localhost:9200/_cluster/settings?pretty -d '
{
  "persistent" : {
    "cluster" : {
      "blocks" : {
        "read_only" : "false"
      }
    }
  }
}'
{
  "acknowledged" : true,
  "persistent" : {
    "cluster" : {
      "blocks" : {
        "read_only" : "false"
      }
    }
  },
  "transient" : { }
}

```

I'm glad I got out of this, but could there be any legitimate reason why this setting should be allowed to be set as persistent? How's this setting _supposed_ to work? Are you supposed to be able to disable the read-only state if it has been enabled as a transient setting or is a full restart supposed to be the only away out? And given the potentially severe impact of such an operation, is that reasonable? [The documentation](https://www.elastic.co/guide/en/elasticsearch/reference/1.6/cluster-update-settings.html#_metadata),

> Have the whole cluster read only (indices do not accept write operations), metadata is not allowed to be modified (create or delete indices).

is pretty terse and perhaps even misleading since it's easy to interpret it like it's only index creation and deletion that's affected by the setting.

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [August 10, 2015, 6:56am UTC](https://discuss.elastic.co/t/recovering-from-cluster-blocks-read-only-true-in-dynamic-settings/27050/4 "2015-08-10T06:56:20Z")

</div>

There are potential reasons, but it seems very edge case for me.

I'd raise a GH issue and see what the dev team reckon. We strive to be as safe as possible with ES so perhaps they can elaborate why this exists, or otherwise remove it.

---

<div class="post-metadata">

**Author:** ![magnusbaeck](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/magnusbaeck/32/44943_2.png) [@magnusbaeck](https://discuss.elastic.co/u/magnusbaeck)\
**Post date:** [August 10, 2015, 8:50am UTC](https://discuss.elastic.co/t/recovering-from-cluster-blocks-read-only-true-in-dynamic-settings/27050/5 "2015-08-10T08:50:46Z")

</div>

Issue created:

> <https://github.com/elastic/elasticsearch/issues/12763>

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 11:56pm UTC](https://discuss.elastic.co/t/recovering-from-cluster-blocks-read-only-true-in-dynamic-settings/27050/6 "2017-07-05T23:56:38Z")

</div>