Most probably it’s because the backing xfs filesystem was not created with ftype=1 option. This is very common if you let the OS installer format the / fs and you just have /var/lib/docker on /.
On newer docker verision (1.13?) with docker info you can see support d_type = false and that indicates your xfs was created with ftype=0 instead of the required ftype=1. This will cause weird issues if you use overlayfs on top of it.
See below issues for detail:
https://github.com/docker/docker/issues/27358
https://github.com/docker/docker/issues/9572
The solution:
-
The easy way - just create another fs for /var/lib/docker with proper option if you have free space on disk. There are two options:
a. Create a ext4 fs with default option and it will be fine.
b. If you prefer xfs, create it like this: mkfs.xfs -n ftype=1 /path/to/your/device -
Or reinstall OS and during installation, make sure you manually create root fs with proper option. You cannot specify that option in the GUI/TUI installer so have to run the command by hand in the terminal provided by the installer. The command is mkfs -t xfs -n ftype=1 /PATH/TO/DEVICE per RH document.
-
Or change your current root fs option from the default ftype=0 to ftype=1. Unfortunately there is no online conversion way exists so you can only do a xfsdump/xfsrestore. Basically you need to prepare a new replacement root partition or disk, manually create xfs on it with proper option, then dump original root fs to the new one, and boot from the new root fs finally.
With any of above solutions applied, in docker info output you will see support d_type = true. Then you won’t run into the issue.
Edit in 2017/02/24: the symptom you may see with overlayfs on a d_type=false fs may be similar - strange errors during some very basic file operations, such as chown, chmod, rm etc… If you happens to run into such problems, and you find d_type=false with docker info, then above solution is for you.