# ES INSISTS on trying to create repos in wrong place

**URL:** <https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358>\
**Category:** Elasticsearch\
**Created:** [September 21, 2017, 3:16pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358 "2017-09-21T15:16:55Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_Carey](https://avatars.discourse-cdn.com/v4/letter/b/ba9def/32.png) [@Bruce\_Carey](https://discuss.elastic.co/u/Bruce_Carey)\
**Post date:** [September 21, 2017, 3:16pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358/1 "2017-09-21T15:16:55Z")

</div>

Setup:

- Azure
- Ubuntu 16.04
- Elasticsearch 1.7.3 (yes I know it's old, but we're not ready to change it yet)

Challenge: We implemented backups. At some point, the path.repo didn't match the place the backup script was trying to create the repo. That was back in April.

It seems that from then until now, the system has kept trying to create those repos, despite restart of Elastic, and a complete system reboot. The Task Queue is empty.

Log sample:

> [2017-09-20 06:15:02,295][WARN][repositories] [Dev Client ES Node 1] failed to create repository [fs][2017-04-25] org.elasticsearch.common.inject.CreationException: Guice creation errors:
> 
> Error injecting constructor, org.elasticsearch.repositories.RepositoryException: [2017-04-25] location [/media/backups2/es/2017-04-25] doesn't match any of the locations specified by path.repo at org.elasticsearch.repositories.fs.FsRepository.(Unknown Source) while locating org.elasticsearch.repositories.fs.FsRepository while locating org.elasticsearch.repositories.Repository

HOW do I get rid of this? It's gotten to the point where this is bringing Elasticsearch down.

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [September 21, 2017, 3:30pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358/2 "2017-09-21T15:30:20Z")

</div>

> Elasticsearch 1.7.3

Well. At least you should really upgrade to latest 1.7 IMHO.

You probably need to add in `elasticsearch.yml` on every node:

```auto
path.repo: /media/backups2/es/2017-04-25

```

---

<div class="post-metadata">

**Author:** ![Bruce\_Carey](https://avatars.discourse-cdn.com/v4/letter/b/ba9def/32.png) [@Bruce\_Carey](https://discuss.elastic.co/u/Bruce_Carey)\
**Post date:** [September 21, 2017, 6:03pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358/3 "2017-09-21T18:03:58Z")

</div>

Hi @dadoonet That date is the name of the repo. The correct path is /media/backups4/es/

Briefly (several days), the script tried /media/backups2/es/. The script and path.repo are now correctly both on backups4. The problem is that it's still trying to create the ones that were incorrect, 5 months later.

What I'm getting at here is, WHERE are these tries coming from? What engine or file or whatever is it that is hanging on to these things?

Yes, I could point something to the wrong path so that it could let go, but I want to know in case this happens again on a production server. There, I won't have the luxury of being able to add a new path to path.repo and restarting ES.

I hope I've clarified this.

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [September 21, 2017, 6:24pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358/4 "2017-09-21T18:24:04Z")

</div>

I believe there is a repository in the cluster state which is referencing it.  
Would be good I think to create a fake dir, start one Es node. Delete the repository.  
Remove that fake dir.  
Restart the node. Then the other nodes.

My 2 cents

---

<div class="post-metadata">

**Author:** ![Bruce\_Carey](https://avatars.discourse-cdn.com/v4/letter/b/ba9def/32.png) [@Bruce\_Carey](https://discuss.elastic.co/u/Bruce_Carey)\
**Post date:** [September 21, 2017, 6:30pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358/5 "2017-09-21T18:30:42Z")

</div>

I assume there's no API to change or delete that reference?

What command would I need to use to check that the reference is indeed in the Cluster State?

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [September 21, 2017, 6:55pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358/6 "2017-09-21T18:55:34Z")

</div>

I'm unsure it's there in:

[https://www.elastic.co/guide/en/elasticsearch/reference/1.7/cluster-state.html](https://www.elastic.co/guide/en/elasticsearch/reference/1.7/cluster-state.html)

May be list the repositories with:

```
GET /_snapshot
```

---

<div class="post-metadata">

**Author:** ![Bruce\_Carey](https://avatars.discourse-cdn.com/v4/letter/b/ba9def/32.png) [@Bruce\_Carey](https://discuss.elastic.co/u/Bruce_Carey)\
**Post date:** [September 21, 2017, 6:58pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358/7 "2017-09-21T18:58:43Z")

</div>

That's it done, thanks! I unfortunately did have to restart the Node, but adding that path to path.repo did allow me to remove the offending items. Thanks again!

---

<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:** [October 19, 2017, 6:58pm UTC](https://discuss.elastic.co/t/es-insists-on-trying-to-create-repos-in-wrong-place/101358/8 "2017-10-19T18:58:51Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
