5

I am following the docker document to test the backup process of data volumes.

The following 2 steps are all OK:

docker create -v /dbdata --name dbdata training/postgres /bin/true
docker run -d --volumes-from dbdata --name db1 training/postgres

But the output of backing up data is:

[root@localhost data]# docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
tar: /backup/backup.tar: Cannot open: Permission denied
tar: Error is not recoverable: exiting now
[root@localhost data]# pwd
/root/data
[root@localhost data]# ls -alt
total 4
drwxrwxrwx.  2 root root    6 May  7 21:33 .
drwxrwx-w-. 15 root root 4096 May  7 21:33 ..

I am working as a root user, so why does it prompt "Permission denied"?

After executing debug command:

docker run --name ins --volumes-from dbdata -v $(pwd):/backup ubuntu sleep 99999 &
docker inspect ins

The output is:

    [{
    "AppArmorProfile": "",
    "Args": [
        "99999"
    ],
    "Config": {
        "AttachStderr": true,
        "AttachStdin": false,
        "AttachStdout": true,
        "Cmd": [
            "sleep",
            "99999"
        ],
        "CpuShares": 0,
        "Cpuset": "",
        "Domainname": "",
        "Entrypoint": null,
        "Env": null,
        "ExposedPorts": null,
        "Hostname": "83e3e1715648",
        "Image": "ubuntu",
        "MacAddress": "",
        "Memory": 0,
        "MemorySwap": 0,
        "NetworkDisabled": false,
        "OnBuild": null,
        "OpenStdin": false,
        "PortSpecs": null,
        "StdinOnce": false,
        "Tty": false,
        "User": "",
        "Volumes": null,
        "WorkingDir": ""
    },
    "Created": "2015-05-08T01:36:35.564512894Z",
    "Driver": "devicemapper",
    "ExecDriver": "native-0.2",
    "ExecIDs": null,
    "HostConfig": {
        "Binds": [
            "/root/data:/backup"
        ],
        "CapAdd": null,
        "CapDrop": null,
        "ContainerIDFile": "",
        "Devices": [],
        "Dns": null,
        "DnsSearch": null,
        "ExtraHosts": null,
        "IpcMode": "",
        "Links": null,
        "LxcConf": [],
        "NetworkMode": "bridge",
        "PidMode": "",
        "PortBindings": {},
        "Privileged": false,
        "PublishAllPorts": false,
        "ReadonlyRootfs": false,
        "RestartPolicy": {
            "MaximumRetryCount": 0,
            "Name": ""
        },
        "SecurityOpt": null,
        "VolumesFrom": [
            "dbdata"
        ]
    },
    "HostnamePath": "/var/lib/docker/containers/83e3e171564841460b206a8699c1890e2b910bcd2232fdc7202cbff9210b5362/hostname",
    "HostsPath": "/var/lib/docker/containers/83e3e171564841460b206a8699c1890e2b910bcd2232fdc7202cbff9210b5362/hosts",
    "Id": "83e3e171564841460b206a8699c1890e2b910bcd2232fdc7202cbff9210b5362",
    "Image": "07f8e8c5e66084bef8f848877857537ffe1c47edd01a93af27e7161672ad0e95",
    "MountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c414,c650",
    "Name": "/ins",
    "NetworkSettings": {
        "Bridge": "docker0",
        "Gateway": "172.17.42.1",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "172.17.0.6",
        "IPPrefixLen": 16,
        "IPv6Gateway": "",
        "LinkLocalIPv6Address": "fe80::42:acff:fe11:6",
        "LinkLocalIPv6PrefixLen": 64,
        "MacAddress": "02:42:ac:11:00:06",
        "PortMapping": null,
        "Ports": {}
    },
    "Path": "sleep",
    "ProcessLabel": "system_u:system_r:svirt_lxc_net_t:s0:c414,c650",
    "ResolvConfPath": "/var/lib/docker/containers/83e3e171564841460b206a8699c1890e2b910bcd2232fdc7202cbff9210b5362/resolv.conf",
    "RestartCount": 0,
    "State": {
        "Error": "",
        "ExitCode": 0,
        "FinishedAt": "0001-01-01T00:00:00Z",
        "OOMKilled": false,
        "Paused": false,
        "Pid": 3614,
        "Restarting": false,
        "Running": true,
        "StartedAt": "2015-05-08T01:36:36.231389015Z"
    },
    "Volumes": {
        "/backup": "/root/data",
        "/dbdata": "/var/lib/docker/vfs/dir/df0378f15f61c8f2e220421968fe181cdcf1a03613218c716c81477dda4bdf76"
    },
    "VolumesRW": {
        "/backup": true,
        "/dbdata": true
    }
}
]

I also try the following command:

[root@localhost data]# docker run --volumes-from dbdata -v $(pwd):/backup -it ubuntu
root@e59c628417f5:/# ls
backup  bin  boot  dbdata  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@e59c628417f5:/# ls -alt
total 72
......
drwxrwxrwx.   2 root root    6 May  8 01:33 backup
......
root@e59c628417f5:/# ls -alt backup/
ls: cannot open directory backup/: Permission denied

So I think the root cause is still involved user permissions.

Nan Xiao
  • 16,671
  • 18
  • 103
  • 164
  • There isn't a backup.tar already there, or /backup without write access is there ? – Ian May 07 '15 at 10:27
  • Can you just run `ls -l /backup`instead of `tar` to see the actual permissions? – Vincent Robert May 07 '15 at 12:06
  • @VincentRobert: `docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata` won't create `/backup` folder automatically? – Nan Xiao May 07 '15 at 12:51

1 Answers1

2

I just tried the commands you listed and they worked for me, both under an OSX platform and also a straight up linux platform. The thing is you are mounting $(pwd) (from your host) to /backup (in the ubuntu image, third docker run above).

I suspect that when you launch the command you are in a directory that is not writable? I tried to get it to fail like this:

mkdir failme
chmod 000 failme
cd failme
docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

But, it worked :-)

So, I cd'ed into a directory that isn't writable by root:

cd /proc
root@kube:/proc# docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
tar: /backup/backup.tar: Cannot open: Permission denied
tar: Error is not recoverable: exiting now

Is it possible that you are starting from a directory that is not writable by root?

Please post the output to these commands: First, run:

docker run --name ins --volumes-from dbdata -v $(pwd):/backup ubuntu sleep 99999 &

(instead of the backup command command you have listed.)

then do an inspect and post those results:

docker inspect ins

And the answer turned out to be that it was the selinux causing the errors. The Original Poster found the answer:

setenforce 0
Greg
  • 6,571
  • 2
  • 27
  • 39
  • I have updated the OP, from the `ls -alt` command output, I can see the `root` user has write priority. – Nan Xiao May 07 '15 at 13:41
  • i don't know then. maybe you should get rid of the $(pwd) and make it explicit, like -v /home/me/backup:/backup. are you running on one of those linux machines with selinux? – Greg May 07 '15 at 13:52
  • `docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata` won't create `/backup` folder automatically? – Nan Xiao May 07 '15 at 14:01
  • i added a couple of debug commands for you to try if you want. the /backup folder already exists in the image you are running by virtue of the -v $(pwd):/backup argument. It is mounted on your current directory (from the docker host). tar will automatically create the file backup.tar, but, the directory /backup must already exist. if you poist your inspect output i can probably figure this out. – Greg May 07 '15 at 14:09
  • I have added the log in OP, please help to check, thanks very much for your kind help! – Nan Xiao May 07 '15 at 14:41
  • i don't know. i asked if you had selinux enabled? also, your ls -alt looks different than mine. is the ls of the /root directory? there is nothing in it? your ls command shows a prompt of [root@localhost backup]# , what does that mean? if you do a /bin/pwd are you in /root/backup? if you are that doesn't make sense, because the inspect shows /root as the binddir. there is something else going on here ! – Greg May 07 '15 at 15:04
  • I am very sorry for my late response! 1) From the output of `sestatus` command, I can see selinux is enabled. 2) Yes, I created a `/root/backup` directory in host. To verify this issue, I removed the `/root/backup`, and used a new `/root/data` directory. Now, I have updated the OP, and all the information is new. Thanks! – Nan Xiao May 08 '15 at 01:35
  • i have heard weird things about selinux, i have seen that some disabled it because of issues that may be like this one. i don't think i can help any more with this. i wish you good luck in finding the problem. best, ---greg – Greg May 08 '15 at 02:53
  • After executing `setenforce 0`, it works! The root cause is about `selinux`. Could you update your answer? Then I can accept it. Thanks very much for your kind and patient help! BTW, do you think it is a bug of docker? – Nan Xiao May 08 '15 at 03:11
  • 2
    `setenforce 0` is useful for troubleshooting, but is not a good solution. Running with `--volume /host/path:/container/path:z` should solve this. See the `-v|--volume` sections of `man docker-run` for more details on the `z` option. – cherdt Dec 20 '18 at 23:08
  • @cherdt you should make an answer. Yours is the right answer. – B.Z. Jan 16 '21 at 04:53