linuxdocker-composelscifs

ls command result NOT CORRECT in docker container in a CIFS mounted directory (via docker-compose)


I have a docker-compose project that starts a service mounting a CIFS share on a container directory. Following is a portion of docker-compose.yml:

version: "2"
...
services:
   myservice:
   ...
      volumes:
        - wr-imp:/opt/data
...
volumes:
  wr-imp:
    driver: local
    driver_opts:
       type: cifs
       device: "//192.168.131.18/"
       o: "addr=192.168.131.18,rw"
       o: "username=abc,password=cba,domain=DOMINIO,file_mode=0777,dir_mode=0777"

The base docker image is Alpine 3.9: https://dl-cdn.alpinelinux.org/alpine/v3.9/.

The docker container myservice starts correctly and all seems OK. If I open a shell in the docker container with "docker exec -it -uroot myservice sh " and cd on /opt/data I can correctly list ("ls") all files in the shared CIFS but only if the number of files is small.

For example if I put 355 files in the shared filesystem (from a windows system for example) I see only 351 files listed with ls command (same count if I run "ls -1 | wc -l" or "ls -ls") from inside docker container (after "docker exec -uroot -it myservice sh" and "cd /opt/data" commands )

If I mount the CIFS on the docker host (a Red Hat 7.6 Maippo distribution) using /etc/fstab:

//192.168.131.18   /DataTest     cifs  vers=1.0,username=abc,password=cba,domain=DOMINIO    0 0 

and if I run command "ls" or "ls -la " or "ls -1 | wc -l" I see 355 files.

It is not a permission problem because

docker version:

Client: 
   Version:           1.13.1
   API version:       1.26
   Package version:   docker-1.13.1-109.gitcccb291.e17_7.x86_64
   Go version:        go1.10.3
   Git commit:        cccb291/1.13.1
   Built:             Thu Jan 30 06:20:45 2020
   OS/Arch:           linux/amd64
Server:
   Version:          1.13.1
   API version:      1.26 (minimum version 1.12)
   Package version:  docker-1.13.1-109.gitcccb291.e17_7.x86_64
   Go version:       go1.10.3
   Git commit:       cccb291/1.13.1
   Built:            Thu Jan 30 06:20:45 2020
   OS/Arch:          linux/amd64
   Experimental:     false

docker-compose version:

docker-compose version 1.24.1, build 4667896b
docker-py version 3.7.3
CPython version 3.6.8
OpenSSL version: OpenSSL 1.1.0j 20 Nov 2018

Solution

  • I can confirm that with the same docker-compose version I'm able to reproduce your issue.

    Nevertheless trying upgrading to Docker version 20.10.7, build f0df350, your issue seems fixed