What should I do to handle the `Permission denied` or `No such file or directory` error, even if I have tried to run `br` using root in vain?

FAQ
1

You need to confirm whether TiKV has access to the backup directory. To back up data, confirm whether TiKV has the write permission. To restore data, confirm whether it has the read permission.

During the backup operation, if the storage medium is the local disk or a network file system (NFS), make sure that the user to start br and the user to start TiKV are consistent (if br and TiKV are on different machines, the users’ UIDs must be consistent). Otherwise, the Permission denied issue might occur.

Running br as the root user might fail due to the disk permission, because the backup files (SST files) are saved by TiKV.

Note:

You might encounter the same problem during data restore. When the SST files are read for the first time, the read permission is verified. The execution duration of DDL suggests that there might be a long interval between checking the permission and running br. You might receive the error message Permission denied after waiting for a long time.

Therefore, it is recommended to check the permission before data restore according to the following steps:

  1. Run the Linux command for process query:

    ps aux | grep tikv-server

    The output is as follows:

    tidb_ouo  9235 10.9  3.8 2019248 622776 ?      Ssl  08:28   1:12 bin/tikv-server --addr 0.0.0.0:20162 --advertise-addr 172.16.6.118:20162 --status-addr 0.0.0.0:20188 --advertise-status-addr 172.16.6.118:20188 --pd 172.16.6.118:2379 --data-dir /home/user1/tidb-data/tikv-20162 --config conf/tikv.toml --log-file /home/user1/tidb-deploy/tikv-20162/log/tikv.log
tidb_ouo  9236  9.8  3.8 2048940 631136 ?      Ssl  08:28   1:05 bin/tikv-server --addr 0.0.0.0:20161 --advertise-addr 172.16.6.118:20161 --status-addr 0.0.0.0:20189 --advertise-status-addr 172.16.6.118:20189 --pd 172.16.6.118:2379 --data-dir /home/user1/tidb-data/tikv-20161 --config conf/tikv.toml --log-file /home/user1/tidb-deploy/tikv-20161/log/tikv.log

    Or you can run the following command:

    ps aux | grep tikv-server | awk '{print $1}'

    The output is as follows:

    tidb_ouo
tidb_ouo

  2. Query the startup information of the cluster using the tiup command:

    tiup cluster list

    The output is as follows:

    [root@Copy-of-VM-EE-CentOS76-v1 br]# tiup cluster list
Starting component `cluster`: /root/.tiup/components/cluster/v1.5.2/tiup-cluster list
Name          User      Version  Path                                               PrivateKey
----          ----      -------  ----                                               ----------
tidb_cluster  tidb_ouo  v5.0.2   /root/.tiup/storage/cluster/clusters/tidb_cluster  /root/.tiup/storage/cluster/clusters/tidb_cluster/ssh/id_rsa

  3. Check the permission for the backup directory. For example, backup is for backup data storage:

    ls -al backup

    The output is as follows:

    [root@Copy-of-VM-EE-CentOS76-v1 user1]# ls -al backup
total 0
drwxr-xr-x  2 root root   6 Jun 28 17:48 .
drwxr-xr-x 11 root root 310 Jul  4 10:35 ..

    From the output of step 2, you can find that the tikv-server instance is started by the user tidb_ouo. But the user tidb_ouo does not have the write permission for backup. Therefore, the backup fails.