Unsuccessful Docker Data-Root Modification Attempt

To install vim, I execute the command “sudo apt-get install vim.” However, I encounter an error stating “bash: sudo: command not found.”
One possible solution is to try passing the user to the docker run command. Does anyone have insights into why docker is not allowing the use of that directory as data-root?


I am attempting to change the default storage directory for my Docker, which is a process I have successfully completed on previous machines.


    "data-root": "/mnt/x/y/docker_data"

where the storage dir looks like

jeremyr@snorble:~$ ls -ltr /mnt/x/y
total 4
drwxrwxrwx 11 jeremyr  5001  122 Mar 19 08:14 docker_data

With the presence of the daemon.json file,

sudo systemctl restart docker

is successful, resulting in

Job for docker.service failed

. The absence of the daemon.json file does not affect
docker restarts

docker run hello-world

operations, which run smoothly. When the daemon.json file is in place,

journalctl -xn

is displayed.

Mar 25 14:20:33 bolt88 systemd[1]: docker.service start request repeated too quickly, refusing to start.
Mar 25 14:20:33 bolt88 systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: Unit docker.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit docker.service has failed.
-- The result is failed.
Mar 25 14:20:33 bolt88 systemd[1]: Unit docker.service entered failed state.
Mar 25 14:20:34 bolt88 sudo[23961]: jeremyr : TTY=pts/18 ; PWD=/home/jeremyr ; USER=root ; COMMAND=/bin/journalctl -xn
Mar 25 14:20:34 bolt88 sudo[23961]: pam_unix(sudo:session): session opened for user root by jeremyr(uid=0)


systemctl status docker.service

merely displays

code=exited, status=1/FAILURE

and in dmesg I see this:

1547:[Mon Mar 25 14:21:41 2019] aufs au_opts_verify:1570:dockerd[20714]: dirperm1 breaks the protection by the permission bits on the lower branch
1548-[Mon Mar 25 14:21:41 2019] device veth34d1dfd entered promiscuous mode
1549-[Mon Mar 25 14:21:41 2019] IPv6: ADDRCONF(NETDEV_UP): veth34d1dfd: link is not ready
1550-[Mon Mar 25 14:21:41 2019] IPv6: ADDRCONF(NETDEV_CHANGE): veth34d1dfd: link becomes ready
1551:[Mon Mar 25 14:21:41 2019] docker0: port 1(veth34d1dfd) entered forwarding state
1552:[Mon Mar 25 14:21:41 2019] docker0: port 1(veth34d1dfd) entered forwarding state
1553:[Mon Mar 25 14:21:41 2019] docker0: port 1(veth34d1dfd) entered disabled state
1554-[Mon Mar 25 14:21:41 2019] device veth34d1dfd left promiscuous mode
1555:[Mon Mar 25 14:21:41 2019] docker0: port 1(veth34d1dfd) entered disabled state
1556-[Mon Mar 25 14:21:59 2019] systemd-sysv-generator[20958]: Ignoring creation of an alias umountiscsi.service for itself

Running on a debian 8.8 setup is Docker version 17.05.0-ce with the build code 89658be.

Is there anyone who can explain why docker is preventing the usage of that directory as the data-root?

Solution 1:

TD;DR — worked on Ubuntu 18.04 just before post

follow the instructions:

sudo systemctl stop docker
sudo rsync -axPS /var/lib/docker/ /mnt/x/y/docker_data #copy all existing data to new location
sudo vi /lib/systemd/system/docker.service # or your favorite text editor

Locate a line similar to the following in the “docker.service” file.

ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Please add

--data-root /mnt/x/y/docker_data

to it, written on a single line.

ExecStart=/usr/bin/dockerd --data-root /mnt/x/y/docker_data -H fd:// --containerd=/run/containerd/containerd.sock

save and quit, then

sudo systemctl daemon-reload
sudo systemctl start docker
docker info | grep "Root Dir"

The expected output of the previous command is the following:

Docker Root Dir: /mnt/x/y/docker_data

that’s it, should’ve done here.


Too Long

version, if you


want to



After conducting an investigation, I discovered several articles, including this one, that discussed various confident solutions. These articles are examples of outdated pages.

  • Integrate the


    option into the docker.service.
  • The method attempted by the question author is to include ”


    ” in the “/etc/docker/daemon.json” file.

After reading solutions from approximately twelve web pages, I found inspiration.

  • Modifying the Configuration of
    Docker Data
  • not a very good solution — not popular, , but the interesting part is below




    has been deprecated in


    .You can use





leads to


. Additionally, the


can be considered as an extended version of


. Therefore, I attempted to incorporate this replacement by including the


option within the docker.service. As a result, voila~

Solution 2:

There is an anomaly with the docker_data.

  • The solution includes four steps:
  • remove the /etc/docker/daemon.json file.
  • ,

  • start docker.
  • ,

  • copy the /var/lib/docker contents to the path you’ve put in /etc/docker/daemon.json.
  • , and

  • put back the file /etc/docker/daemon.json and restart docker.
  • .

Solution 3:

While I may not be well-versed in docker, I noticed a message in your log stating that “dirperm1 disrupts the protection through permission bits on the lower branch.” Additionally, I observed the following entry: “drwxrwxrwx 11 jeremyr 5001 122 Mar 19 08:14 docker_data.

According to my understanding, the directory needs to grant access permission to the docker daemon. Is the “docker” group represented by the number 5001?

If the daemon is executed with root permission, it should not occur.

Solution 4:

Verify the docker version on your machine.

docker --version

I encountered the same problem, and it was resolved by updating the available Docker to the latest version.

No mention of such information is found in the documentation provided on docker’s official website.

upgrade docker
, proceed to restart the docker.

systemctl restart docker

Once the error is resolved, the implementation of new changes will begin to show.

Frequently Asked Questions