# Repository error is generated while creating snapshot

**URL:** <https://discuss.elastic.co/t/repository-error-is-generated-while-creating-snapshot/186209>\
**Category:** Elasticsearch\
**Created:** [June 18, 2019, 9:17am UTC](https://discuss.elastic.co/t/repository-error-is-generated-while-creating-snapshot/186209 "2019-06-18T09:17:04Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vineeth\_Ananthula1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vineeth_ananthula1/32/47851_2.png) [@Vineeth\_Ananthula1](https://discuss.elastic.co/u/Vineeth_Ananthula1)\
**Post date:** [June 18, 2019, 9:17am UTC](https://discuss.elastic.co/t/repository-error-is-generated-while-creating-snapshot/186209/1 "2019-06-18T09:17:04Z")

</div>

I have configured path.repo = ["/tata"] in elasticsearch.yml of both master and child node. My snapshot query looks like this.

```
PUT /_snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/tata"
  }
}

```

But when I register a folder for a snapshot. I get the error.

```
{
  "error": {
    "root_cause": [
      {
        "type": "repository_verification_exception",
        "reason": "[my_backup] [[uo89wL8tTwyUDb89LUZxxg, 'RemoteTransportException[[node-1][100.97.22.29:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[my_backup] store location [/tata] is not accessible on the node [{node-1}{uo89wL8tTwyUDb89LUZxxg}{PtpAn9Q4QWCqHp2_VXQaGQ}{100.97.22.29}{100.97.22.29:9300}{ml.machine_memory=16692609024, xpack.installed=true, ml.max_open_jobs=20}]]; nested: AccessDeniedException[/tata/tests-Msfm88cJQVuyLlYvoPw6aA/data-uo89wL8tTwyUDb89LUZxxg.dat];']]"
      }
    ],
    "type": "repository_verification_exception",
    "reason": "[my_backup] [[uo89wL8tTwyUDb89LUZxxg, 'RemoteTransportException[[node-1][100.97.22.29:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[my_backup] store location [/tata] is not accessible on the node [{node-1}{uo89wL8tTwyUDb89LUZxxg}{PtpAn9Q4QWCqHp2_VXQaGQ}{100.97.22.29}{100.97.22.29:9300}{ml.machine_memory=16692609024, xpack.installed=true, ml.max_open_jobs=20}]]; nested: AccessDeniedException[/tata/tests-Msfm88cJQVuyLlYvoPw6aA/data-uo89wL8tTwyUDb89LUZxxg.dat];']]"
  },
  "status": 500
}

```

Th output of mount is given below  
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)  
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)  
devtmpfs on /dev type devtmpfs (rw,nosuid,size=8135104k,nr\_inodes=2033776,mode=755)  
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)  
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)  
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)  
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)  
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)  
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release\_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)  
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)  
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)  
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)  
cgroup on /sys/fs/cgroup/perf\_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf\_event)  
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)  
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)  
cgroup on /sys/fs/cgroup/net\_cls,net\_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net\_prio,net\_cls)  
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)  
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)  
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)  
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)  
configfs on /sys/kernel/config type configfs (rw,relatime)  
/dev/mapper/vg\_root-lv\_root on / type ext4 (rw,relatime,data=ordered)  
systemd-1 on /proc/sys/fs/binfmt\_misc type autofs (rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe\_ino=12559)  
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)  
debugfs on /sys/kernel/debug type debugfs (rw,relatime)  
mqueue on /dev/mqueue type mqueue (rw,relatime)  
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)  
/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered)  
sunrpc on /var/lib/nfs/rpc\_pipefs type rpc\_pipefs (rw,relatime)  
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1630140k,mode=700,uid=1000,gid=1000)  
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=1630140k,mode=700)  
tmpfs on /run/user/1007 type tmpfs (rw,nosuid,nodev,relatime,size=1630140k,mode=700,uid=1007,gid=1008)  
tmpfs on /run/user/1003 type tmpfs (rw,nosuid,nodev,relatime,size=1630140k,mode=700,uid=1003,gid=1004)  
100.97.22.28:/tata on /tata type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=100.97.22.29,local\_lock=none,addr=100.97.22.28)

I have mounted the tata folder in the nodes (Total no of nodes=2) as an nfs mount.  
I have referred to this[link](https://discuss.elastic.co/t/why-does-creating-a-repository-fail/22697/2)  
I found the explanation confusing.  
So, What can be the reason for this error  
So how can I correct this error?

---

<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:** [June 18, 2019, 9:32am UTC](https://discuss.elastic.co/t/repository-error-is-generated-while-creating-snapshot/186209/2 "2019-06-18T09:32:13Z")

</div>

Does this help?

> [@Unable to register NFS for snapshot](https://discuss.elastic.co/t/unable-to-register-nfs-for-snapshot/186026/2):
>
> NFS permission issues are often because the Elasticsearch process is not running as the same numerical UID or GID on each node, without compensating for this in the NFS configuration, meaning that when one node creates a subdirectory of the repository it is not possible for the other nodes to modify it. That is the first thing I would check.

---

<div class="post-metadata">

**Author:** ![Vineeth\_Ananthula1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vineeth_ananthula1/32/47851_2.png) [@Vineeth\_Ananthula1](https://discuss.elastic.co/u/Vineeth_Ananthula1)\
**Post date:** [June 18, 2019, 9:40am UTC](https://discuss.elastic.co/t/repository-error-is-generated-while-creating-snapshot/186209/3 "2019-06-18T09:40:13Z")

</div>

@David Turner Thanks for the reply. **You mean that the snapshot directory in all the nodes should have the same userid and groupid of elasticsearch**. As you said in my nodes the elasticsearch userid and group id are different. If so, Please tell me how can I proceed further in making the ids same ?

---

<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:** [June 18, 2019, 9:45am UTC](https://discuss.elastic.co/t/repository-error-is-generated-while-creating-snapshot/186209/4 "2019-06-18T09:45:43Z")

</div>

The answer very much depends on the details of your environment and isn't really something I can help you with here as it's outside of Elasticsearch's control, sorry. I would look to your OS documentation or a local sysadmin for help with this.

---

<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 16, 2019, 9:45am UTC](https://discuss.elastic.co/t/repository-error-is-generated-while-creating-snapshot/186209/5 "2019-07-16T09:45:44Z")

</div>

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