# Error when creating a Snapshot Repository

**URL:** <https://discuss.elastic.co/t/error-when-creating-a-snapshot-repository/152587>\
**Category:** Elasticsearch\
**Created:** [October 16, 2018, 5:12am UTC](https://discuss.elastic.co/t/error-when-creating-a-snapshot-repository/152587 "2018-10-16T05:12:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zamiell](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/zamiell/32/51665_2.png) [@Zamiell](https://discuss.elastic.co/u/Zamiell)\
**Post date:** [October 16, 2018, 5:12am UTC](https://discuss.elastic.co/t/error-when-creating-a-snapshot-repository/152587/1 "2018-10-16T05:12:06Z")

</div>

Greetings!

I'm following the Snapshot and Restore guide listed here:  
[https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html)

I'm running a fairly large ElasticSearch cluster on 6.4.2. All my nodes run CentOS. I've set up an NFS mount for every node in the cluster, as explained in the guide.

However, upon creating/verifying a new snapshot repository, I get an error:

```auto
{
  "error" : {
    "root_cause" : [
      {
        "type" : "repository_verification_exception",
[snip]

```

and

```auto
nested: RepositoryMissingException[[my_backup] missing];']

```

and

```auto
nested: RepositoryVerificationException[[my_backup] store location [/mnt/elasticsearch-backup/kibana_backup] is not accessible on the node [{es-18}

```

and

```auto
nested: AccessDeniedException[/mnt/elasticsearch-backup/kibana_backup/tests-F2_sNB9QSJyRjrAOxigw2g/data-kEVEhOgBRni_hTeGVGnJsQ.dat];']

```

and then more of the same.

So at first this looks like a permissions issue, but I don't think that it is. Both `/mnt/elasticsearch-backup` and `/mnt/elasticsearch-backup/kibana_backup` have 777 permissions. Furthermore, I've verified that all of them are connected properly with the `mount` command, and when I create a file on one node, it does appear in the directory of another node, so the NFS mount appears to be functioning correctly.

I did some Google searching and I wasn't able to find anything. Anyone have any tips?

Thank you,

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [October 16, 2018, 7:43am UTC](https://discuss.elastic.co/t/error-when-creating-a-snapshot-repository/152587/2 "2018-10-16T07:43:06Z")

</div>

It's better to share the whole stack trace of the exception and the whole error message - even though they can be quite long, they also include useful information.

I'm going to guess that the Elasticsearch process is not running as the same _numerical_ UID or GID on each node, and your NFS configuration does not compensate for this, meaning that when one node creates a subdirectory of the repository it is not possible for the other nodes to modify it.

---

<div class="post-metadata">

**Author:** ![Zamiell](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/zamiell/32/51665_2.png) [@Zamiell](https://discuss.elastic.co/u/Zamiell)\
**Post date:** [October 16, 2018, 4:41pm UTC](https://discuss.elastic.co/t/error-when-creating-a-snapshot-repository/152587/3 "2018-10-16T16:41:31Z")

</div>

Thank you @DavidTurner. I'll ensure that all ElasticSearch users are on the same UID/GID, and then try again.

I didn't want to post the full stack trace out of fear of leaking something sensitive.

---

<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:** [November 13, 2018, 4:41pm UTC](https://discuss.elastic.co/t/error-when-creating-a-snapshot-repository/152587/4 "2018-11-13T16:41:33Z")

</div>

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