I. Problem Description
Today, after testing encrypted GitLab backup files, decrypting them, and then restoring GitLab, the recovery failed. The following error was reported:
tar: db: Unable mkdir: insufficient privilege
tar: db: Unable mkdir: insufficient privilege
tar: db/database.sql.gz: Unable open: No file or directory
tar: uploads.tar.gz: Unable open: insufficient privilege
tar: builds.tar.gz: Unable open: insufficient privilege
tar: artifacts.tar.gz: Unable open: insufficient privilege
tar: pages.tar.gz: Unable open: insufficient privilege
tar: lfs.tar.gz: Unable open: insufficient privilege
tar: backup_information.yml: Unable open: insufficient privilege
tar: Due to the previous error, exit from the previous error status
unpacking backup failed
Detailed errors are as follows:
tar: repositories: Unable mkdir: insufficient privilege tar: repositories/caokuishun: Unable mkdir: No file or directory tar: repositories: Unable mkdir: insufficient privilege tar: repositories/caokuishun/EKOCelluarViewMod.bundle: Unable open: No file or directory tar: repositories: Unable mkdir: insufficient privilege tar: repositories/caokuishun/SDKTest.bundle: Unable open: No file or directory tar: repositories: Unable mkdir: insufficient privilege tar: repositories/ReactNative: Unable mkdir: No file or directory tar: repositories: Unable mkdir: insufficient privilege tar: repositories/ReactNative/Binding.bundle: Unable open: No file or directory tar: db: Unable mkdir: insufficient privilege tar: db: Unable mkdir: insufficient privilege tar: db/database.sql.gz: Unable open: No file or directory tar: uploads.tar.gz: Unable open: insufficient privilege tar: builds.tar.gz: Unable open: insufficient privilege tar: artifacts.tar.gz: Unable open: insufficient privilege tar: pages.tar.gz: Unable open: insufficient privilege tar: lfs.tar.gz: Unable open: insufficient privilege tar: backup_information.yml: Unable open: insufficient privilege tar: Due to the previous error, exit from the previous error status unpacking backup failed [root@localhost backups]# cd ../ [root@localhost gitlab]# ll //Total dosage 16 drwxr-xr-x. 2 root root 58 10 Month 2316:25 backups -rw-------. 1 root root 38 10 Month 2018:07 bootstrapped drwx------. 2 git root 44 10 Month 2316:00 gitaly drwx------. 3 git root 25 10 Month 2316:47 git-data drwxr-xr-x. 3 git root 19 10 Month 2017:18 gitlab-ci drwxr-xr-x. 2 git root 31 10 Month 2018:08 gitlab-monitor drwxr-xr-x. 9 git root 4096 10 Month 2018:07 gitlab-rails drwx------. 2 git root 23 10 Month 2018:06 gitlab-shell drwxr-x---. 2 git gitlab-www 51 10 Month 2316:00 gitlab-workhorse drwx------. 3 root root 68 10 Month 2316:10 logrotate drwxr-x---. 9 root gitlab-www 4096 10 Month 2316:00 nginx drwxr-xr-x. 3 root root 31 10 Month 2018:07 node-exporter drwx------. 2 gitlab-psql root 25 10 Month 2018:08 postgres-exporter drwxr-xr-x. 3 gitlab-psql root 77 10 Month 2316:00 postgresql drwxr-x---. 3 gitlab-prometheus root 38 10 Month 2018:07 prometheus drwxr-x---. 2 gitlab-redis git 57 10 Month 2316:47 redis -rw-r--r--. 1 root root 40 10 Month 2017:18 trusted-certs-directory-hash
II. Solving the Problem
2.1 Conjecture is that there may be insufficient disk space. Use df-h to view disk space
[root@localhost ~]# cd /var/opt/gitlab/ [root@localhost gitlab]# ll //Total dosage 16 drwx------. 3 git root 77 10 Month 2317:03 backups -rw-------. 1 root root 38 10 Month 2018:07 bootstrapped drwx------. 2 git root 44 10 Month 2316:00 gitaly drwx------. 3 git root 25 10 Month 2316:47 git-data drwxr-xr-x. 3 git root 19 10 Month 2017:18 gitlab-ci drwxr-xr-x. 2 git root 31 10 Month 2018:08 gitlab-monitor drwxr-xr-x. 9 git root 4096 10 Month 2018:07 gitlab-rails drwx------. 2 git root 23 10 Month 2018:06 gitlab-shell drwxr-x---. 2 git gitlab-www 51 10 Month 2316:00 gitlab-workhorse drwx------. 3 root root 68 10 Month 2317:10 logrotate drwxr-x---. 9 root gitlab-www 4096 10 Month 2316:00 nginx drwxr-xr-x. 3 root root 31 10 Month 2018:07 node-exporter drwx------. 2 gitlab-psql root 25 10 Month 2018:08 postgres-exporter drwxr-xr-x. 3 gitlab-psql root 77 10 Month 2316:00 postgresql drwxr-x---. 3 gitlab-prometheus root 38 10 Month 2018:07 prometheus drwxr-x---. 2 gitlab-redis git 57 10 Month 2317:02 redis -rw-r--r--. 1 root root 40 10 Month 2017:18 trusted-certs-directory-hash [root@localhost gitlab]# df -h //File system capacity used Available% mount point /dev/sda2 462G 197G 265G 43% / devtmpfs 3.8G 0 3.8G 0% /dev tmpfs 3.8G 88K 3.8G 1% /dev/shm tmpfs 3.8G 9.0M 3.8G 1% /run tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup tmpfs 775M 16K 775M 1% /run/user/42 tmpfs 775M 0 775M 0% /run/user/0 [root@localhost gitlab]#
From what command execution to see, space is still sufficient, there are 265G available.
2.2 Guess the GitLab backup package was damaged after decompression.
Comparing the decrypted Gitlab backup package with the original Gitlab backup package, the number of bytes is 125403678720, and the file should be undamaged.
2.3 Guess that the permissions of the / var/opt/gitlab/backups directory are not right?
Check the permissions and owner of the / var/opt/gitlab/backups directory as follows:
[root@localhost gitlab-rails]# cd /var/opt/gitlab/backups/ [root@localhost backups]# ll //Total dosage 122464536 -rwxrwxrwx. 1 root root 125403678720 10 Month 2315:33 1540263550_2018_10_23_9.4.3_gitlab_backup.tar [root@localhost backups]# tar xf uploads.tar.gz -C /var/opt/gitlab/gitlab-rails/uploads tar: uploads.tar.gz: Unable open: No file or directory tar: Error is not recoverable: exiting now [root@localhost backups]# cd ../ [root@localhost gitlab]# ll //Total dosage 16 drwxr-xr-x. 2 root root 58 10 Month 2316:25 backups -rw-------. 1 root root 38 10 Month 2018:07 bootstrapped drwx------. 2 git root 44 10 Month 2316:00 gitaly drwx------. 3 git root 25 10 Month 2316:47 git-data drwxr-xr-x. 3 git root 19 10 Month 2017:18 gitlab-ci drwxr-xr-x. 2 git root 31 10 Month 2018:08 gitlab-monitor drwxr-xr-x. 9 git root 4096 10 Month 2018:07 gitlab-rails drwx------. 2 git root 23 10 Month 2018:06 gitlab-shell drwxr-x---. 2 git gitlab-www 51 10 Month 2316:00 gitlab-workhorse drwx------. 3 root root 68 10 Month 2316:10 logrotate drwxr-x---. 9 root gitlab-www 4096 10 Month 2316:00 nginx drwxr-xr-x. 3 root root 31 10 Month 2018:07 node-exporter drwx------. 2 gitlab-psql root 25 10 Month 2018:08 postgres-exporter drwxr-xr-x. 3 gitlab-psql root 77 10 Month 2316:00 postgresql drwxr-x---. 3 gitlab-prometheus root 38 10 Month 2018:07 prometheus drwxr-x---. 2 gitlab-redis git 57 10 Month 2316:47 redis -rw-r--r--. 1 root root 40 10 Month 2017:18 trusted-certs-directory-hash [root@localhost gitlab]# chown git backups/ [root@localhost gitlab]# chmod 700 backups/ [root@localhost gitlab]# cd backups/ [root@localhost backups]# sudo gitlab-rake gitlab:backup:restore BACKUP=1540263550_2018_10_23_9.4.3 Unpacking backup ...
The modified / var/opt/gitlab/backups directory permissions and owner are as follows:
[root@localhost gitlab]# [root@localhost gitlab]# [root@localhost gitlab]# pwd /var/opt/gitlab [root@localhost gitlab]# ll //Total dosage 16 drwx------. 3 git root 77 10 Month 2317:03 backups -rw-------. 1 root root 38 10 Month 2018:07 bootstrapped drwx------. 2 git root 44 10 Month 2316:00 gitaly drwx------. 3 git root 25 10 Month 2316:47 git-data drwxr-xr-x. 3 git root 19 10 Month 2017:18 gitlab-ci drwxr-xr-x. 2 git root 31 10 Month 2018:08 gitlab-monitor drwxr-xr-x. 9 git root 4096 10 Month 2018:07 gitlab-rails drwx------. 2 git root 23 10 Month 2018:06 gitlab-shell drwxr-x---. 2 git gitlab-www 51 10 Month 2316:00 gitlab-workhorse drwx------. 3 root root 68 10 Month 2317:10 logrotate drwxr-x---. 9 root gitlab-www 4096 10 Month 2316:00 nginx drwxr-xr-x. 3 root root 31 10 Month 2018:07 node-exporter drwx------. 2 gitlab-psql root 25 10 Month 2018:08 postgres-exporter drwxr-xr-x. 3 gitlab-psql root 77 10 Month 2316:00 postgresql drwxr-x---. 3 gitlab-prometheus root 38 10 Month 2018:07 prometheus drwxr-x---. 2 gitlab-redis git 57 10 Month 2317:17 redis -rw-r--r--. 1 root root 40 10 Month 2017:18 trusted-certs-directory-hash [root@localhost gitlab]#
I just reacted, before I deleted the / var/opt/gitlab directory, and then used the root user to create a new / var/opt/gitlab directory, which led to inconsistencies. The user of Gitlab recovery operation is git, so there is no right to operate the new directory created by root user.
After modifying the privileges and the users, the execution of the commands will be normal! uuuuuuuuuuu
Author: Ouyang Peng welcomes reprinting, sharing with others is the source of progress!
Please retain the original address for reprinting: https://blog.csdn.net/qq446282412/article/details/83310185
If this article is helpful to you, you are welcome to scan the code below, and Alipay and WeChat pay two dimensional code to reward this article.
