If the target of a named volume is a symbolic link in the docker image, the target fails to appear in the container

[aki-k]

Description

If the target of a named volume is a symbolic link in the docker image, the target fails to appear in the container

Steps to reproduce the issue:

1. Create a Docker compose file with the named volume configuration:

      - type: volume
        source: authentication_1_lock_dir
        target: /var/lock/dirsrv
      - type: volume
        source: authentication_1_run_dir
        target: /var/run/dirsrv

volumes:
  authentication_1_lock_dir:
  authentication_1_run_dir:

2. docker stack deploy previous compose file

Describe the results you received:

/var/lock/dirsrv and /var/run/dirsrv fail to appear in the container.

The named volumes are created on the Docker host.

Describe the results you expected:

/var/lock/dirsrv and /var/run/dirsrv should appear in the container.

The problem seems to be caused by the symbolic links in the docker image for

lrwxrwxrwx. 1 root root 11 Dec 4 2018 /var/lock -> ../run/lock
lrwxrwxrwx. 1 root root 6 Dec 4 2018 /var/run -> ../run

After I change the named volume configuration to:

      - type: volume
        source: authentication_1_lock_dir
        target: /run/lock/dirsrv
      - type: volume
        source: authentication_1_run_dir
        target: /run/dirsrv

volumes:
  authentication_1_lock_dir:
  authentication_1_run_dir:

and docker stack deploy the compose file again, the target dirs /run/lock/dirsrv and /run/dirsrv (and also /var/lock/dirsrv and /var/run/dirsrv) appear in the container.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:21:07 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       74b1e89
  Built:            Thu Jul 25 21:19:36 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 oci-add-hooks:
  Version:          
  GitCommit:        oci-add-hooks-b25d3bd0678c9812f7bdd6807209dbb89145a1cd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker info:

Client:
 Debug Mode: false

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 2
 Server Version: 19.03.1
 Storage Driver: btrfs
  Build Version: Btrfs v4.9.1
  Library Version: 102
 Logging Driver: json-file
 Cgroup Driver: systemd
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: active
  NodeID: h9uql2vzg27d2ibbif3qqgl4d
  Is Manager: true
  ClusterID: m5nki550bdphhb7emeu2yq2d5
  Managers: 3
  Nodes: 3
  Default Address Pool: 10.0.0.0/8  
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 10.0.0.2
  Manager Addresses:
   10.0.0.1:2377
   10.0.0.2:2377
   10.0.0.3:2377
 Runtimes: oci-add-hooks runc
 Default Runtime: oci-add-hooks
 Init Binary: docker-init
 containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc version: oci-add-hooks-b25d3bd0678c9812f7bdd6807209dbb89145a1cd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
  selinux
  userns
 Kernel Version: 5.1.16-1.el7.elrepo.x86_64
 Operating System: CentOS Linux 7 (Core)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.852GiB
 Name: hostname
 ID: EMCY:GYP4:AUSJ:6UM2:WMH2:KGJA:PJBW:CTJ7:BUQO:UA53:R7M5:FCGO
 Docker Root Dir: /var/lib/docker/262144.262144
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

Running these VMs in an IaaS cloud.

[aki-k]

More specifically, the problem seems to be caused by the symbolic links

/var/lock -> ../run/lock
/var/run -> ../run