Fixes a regression from the volumes refactor where the vfs graphdriver
was setting labels for volumes to `s0` so that they can both be written
to by the container and shared with other containers.
When moving away from vfs this was never re-introduced.
Since this needs to happen regardless of volume driver, this is
implemented outside of the driver.
Fixes issue where `z` and `Z` labels are not set for bind-mounts.
Don't lock while creating volumes
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
UnmountVolumes used to also unmount 'specialMounts' but it no longer does after
a recent refactor of volumes. This patch corrects this behavior to include
unmounting of `networkMounts` which replaces `specialMounts` (now dead code).
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Signed by all authors:
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Signed-off-by: David Calavera <david.calavera@gmail.com>
Signed-off-by: Jeff Lindsay <progrium@gmail.com>
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Signed-off-by: Luke Marsden <luke@clusterhq.com>
Signed-off-by: David Calavera <david.calavera@gmail.com>
Due to the importance of path safety, the internal sanitisation wrappers
for volumes and containers should be exposed so other parts of Docker
can benefit from proper path sanitisation.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> (github: cyphar)
- Mount struct now called volumeMount
- Merged volume creation for each volume type (volumes-from, binds, normal
volumes) so this only happens in once place
- Simplified container copy of volumes (for when `docker cp` is a
volume)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
daemon/volumes.go
This SetFileCon call made no sense, it was changing the labels of any
directory mounted into the containers SELinux label. If it came from me,
then I apologize since it is a huge bug.
The Volumes Mount code should optionally do this, but it should not always
happen, and should never happen on a --privileged container.
The change to
daemon/graphdriver/vfs/driver.go, is a simplification since this it not
a relabel, it is only a setting of the shared label for docker volumes.
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
Create container job could fail because a container specified with
`--volumes-from` does not exist. This error is not propagated to client
though. Instead it's recognized by higher levels as "image not found".
Client then tries to pull the image and launch the container again.
This patch changes the lower level error message so that it's not
recognized as "image not found" and thus it's propagated to client.
Signed-off-by: Michal Minar <miminar@redhat.com>
Fixes#9981
Allows a volume which was created by docker (ie, in
/var/lib/docker/vfs/dir) to be used as a Bind argument via the container
start API and overwrite an existing volume.
For example:
```bash
docker create -v /foo --name one
docker create -v /foo --name two
```
This allows the volume from `one` to be passed into the container start
API as a bind to `two`, and it will overwrite it.
This was possible before 7107898d5c
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Addresses: #10618
Given that the user has no notification that they tried to bind mount
different directories on the same target in the container, this errors
out in that case, without changing the current code allowing for
--volumes-from to trump -v/VOLUME specifications.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Fixes#9629#9768
A couple of issues:
1) Volume config is not restored if we couldn't find it with the graph
driver, but bind-mounts would never be found by the graph driver since
they aren't in that dir
2) container volumes were only being restored if they were found in the
volumes repo, but volumes created by old daemons wouldn't be in the
repo until the container is at least started.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Fixes#9709
In cases where the volumes-from container is removed and the consuming
container is restarted, docker was trying to re-apply volumes from that
now missing container, which is uneccessary since the volumes are
already applied.
Also cleaned up the volumes-from parsing function, which was doing way more than
it should have been.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Currently this content gets a system label and is not writable based on
SELinux controls. This patch will set the labels to the correct label.
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
Running parseVolumesFromSpec on all VolumesFrom specs before initialize
any mounts endures that we don't leave container.Volumes in an
inconsistent (partially initialized) if one of out mount groups is not
available (e.g. the container we're trying to mount from does not
exist).
Keeping container.Volumes in a consistent state ensures that next time
we Start() the container, it'll run prepareVolumes() again.
The attached test demonstrates that when a container fails to start due
to a missing container specified in VolumesFrom, it "remembers" a Volume
that worked.
Fixes: #8726
Signed-off-by: Thomas Orozco <thomas@orozco.fr>
Fixes#1992
Right now when you `docker cp` a path which is in a volume, the cp
itself works, however you end up getting files that are in the
container's fs rather than the files in the volume (which is not in the
container's fs).
This makes it so when you `docker cp` a path that is in a volume it
follows the volume to the real path on the host.
archive.go has been modified so that when you do `docker cp mydata:/foo
.`, and /foo is the volume, the outputed folder is called "foo" instead
of the volume ID (because we are telling it to tar up
`/var/lib/docker/vfs/dir/<some id>` and not "foo", but the user would be
expecting "foo", not the ID
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
When a container is restarted all the volume configs are parsed again.
Even if the volume was already handled in a previous start it was still
calling "FindOrCreateVolume" on the volume repo causing a new volume to
be created.
This wasn't being detected because as part of the mount initialization
it checks to see if the the _mount_ was already initialized, but this
happens after the parsing of the configs.
So a check is added during parsing to skip a volume which was already
created for that container.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Volume refs were not being restored on daemon restart.
This made it possible to remove a volume being used by other containers
after a daemon restart.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Prior to the volumes re-factor, data was not being copied on
volumes-from or host-mounted volumes.
After the re-factor, data was being copied for volumes-from.
This reverts this unintentional change in behavior.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Needed to check if the mode was invalid and return error, not valid and
return error.
This didn't get picked up because the existing integration-cli tests
were all either expecting errors when a valid mode was passed in (e.g.
"ro" passed in, we expected an error because it was testing write). So
modified a test which was testing for "rw" to actually pass in "rw"
instead of assuming the "rw"
Docker-DCO-1.1-Signed-off-by: Brian Goff <bgoff@cpuguy83-mbp.home> (github: cpuguy83)
Now that the archive package does not depend on any docker-specific
packages, only those in pkg and vendor, it can be safely moved into pkg.
Signed-off-by: Rafe Colton <rafael.colton@gmail.com>
