Docker will not start when docker path is an unassigned device


Recommended Posts

unRAID OS Version: 6.2

 

Description: When the docker image is assigned to a device mounted with the unassigned devices plugin, Docker fails to start.

 

How to reproduce: Assign the docker image to a UD mounted device - /mnt/disks/test/docker.  Test is a disk mounted with UD and mounted with the name "test".  Create a folder on the "test" disk and set ownership to [nobody users].

 

Expected results: Docker will start and create a docker.img if one does not exist.

 

Actual results: At the command line type '/etc/rc.d/rc.docker start' and the error "no image mounted at /var/lib/docker" is displayed and docker is not started.

 

Other information: A user should be able to create a docker.img file on a drive not an array or cache drive.  VM files and appdata files can be mapped to a UD mounted device.

Link to comment

I would think this is a feature request rather than a defect report as the fact that the docker image file can no longer be on an Unassigned Device is a stated limitation.

 

Since the limitation is apparently due to a race condition between docker being started and the UD plugin mounting the drive I think that one way that might work around this limitation is to handle the mounting of the drive via an entry in the 'go' file before it starts up emhttp.  That way the race condition cannot occur.

Link to comment

I would think this is a feature request rather than a defect report as the fact that the docker image file can no longer be on an Unassigned Device is a stated limitation.

 

Since the limitation is apparently due to a race condition between docker being started and the UD plugin mounting the drive I think that one way that might work around this limitation is to handle the mounting of the drive via an entry in the 'go' file before it starts up emhttp.  That way the race condition cannot occur.

 

If appdata and VMs can be mounted on a UD device, why not dockers?  Where did you read that this is a limitation in 6.2?  I didn't catch that.

Link to comment

I would think this is a feature request rather than a defect report as the fact that the docker image file can no longer be on an Unassigned Device is a stated limitation.

 

Since the limitation is apparently due to a race condition between docker being started and the UD plugin mounting the drive I think that one way that might work around this limitation is to handle the mounting of the drive via an entry in the 'go' file before it starts up emhttp.  That way the race condition cannot occur.

Actually Tom said it should work.  It was Squid (if I remember correctly) that was saying it wouldn't work - which it apparently doesn't.  Or am I wrong and they were only talking about appdata?  Just don't remember positively and not intrested in searching for it quite frankly.
Link to comment

unRAID OS Version: 6.2

 

Description: When the docker image is assigned to a device mounted with the unassigned devices plugin, Docker fails to start.

 

How to reproduce: Assign the docker image to a UD mounted device - /mnt/disks/test/docker.  Test is a disk mounted with UD and mounted with the name "test".  Create a folder on the "test" disk and set ownership to [nobody users].

 

Expected results: Docker will start and create a docker.img if one does not exist.

 

Actual results: At the command line type '/etc/rc.d/rc.docker start' and the error "no image mounted at /var/lib/docker" is displayed and docker is not started.

 

Other information: A user should be able to create a docker.img file on a drive not an array or cache drive.  VM files and appdata files can be mapped to a UD mounted device.

Need a system log.

Link to comment

docker.cfg:

DOCKER_ENABLED="yes"
DOCKER_IMAGE_FILE="/mnt/disks/test/docker/docker.img"
DOCKER_IMAGE_SIZE="10"
DOCKER_APP_CONFIG_PATH="/mnt/cache/appdata/"
DOCKER_APP_UNRAID_PATH=""
DOCKER_AUTHORING_MODE="no"

 

There are some checks on the DOCKER_IMAGE_FILE that take place before starting docker:

1. If the first path component is "/mnt" then the second path component must be a mounted file system, that is "/mnt/disks" must be a mount point.  In normal case we have /mnt/disk1, /mnt/disk2, /mnt/user, etc., all of which should be mount points.  If they are not, eg suppose for some reason /mnt/disk1 exists but nothing mounted there, then the docker image file could be created in RAM - not good.  If the first component of this path is not "/mnt" then no further checks are done - it assumes you know what you are doing  ;)

2. Next it checks that directory that contains the docker image exists, ie, it does a

"mkdir -p /mnt/disks/test/docker"

3. Finally it checks if the image file exists, creates if not, and then loopback mounts it.

 

Probably your case is failing first test.  My suggestion is don't use mount points inside /mnt - I know some plugins might do that but not officially recommended.

Link to comment

 

 

My suggestion is don't use mount points inside /mnt - I know some plugins might do that but not officially recommended.

Just a clarification here because my understanding is that dockerMan only supports slave mode mounts within /mnt/disks and this is an extremely useful thing to have.

 

If you don't recommend mounts within /mnt can the slave mode be expanded to support any mount?

 

 

Sent from my LG-D852 using Tapatalk

 

 

Link to comment

Just to potentially confuse the issue some more, I have mine mounted using dlandon's Unassigned Devices plugin and it's working fine...

 

 

Happy to provide logs if anybody thinks they'll be useful..

Actually, that might really help dlandon and Tom simply because you're not using the stock mounts from UD (/mnt/disks)  You've changed it to /mnt/virtualization, and AFAIK every who's failed to get this working was using /mnt/disks, but also afaik you're the first who's got it working who's posted a screenshot.

 

Link to comment

Just to potentially confuse the issue some more, I have mine mounted using dlandon's Unassigned Devices plugin and it's working fine...

 

 

Happy to provide logs if anybody thinks they'll be useful..

Actually, that might really help dlandon and Tom simply because you're not using the stock mounts from UD (/mnt/disks)  You've changed it to /mnt/virtualization, and AFAIK every who's failed to get this working was using /mnt/disks, but also afaik you're the first who's got it working who's posted a screenshot.

 

That makes sense because the 2nd component of the path is a mount point - that is what's being checked.  Actually Eric shamed me into doing the proper fix: if the docker (and libvirt) image file path starts with /mnt then we will examine each directory component one-by-one from left to right until we hit a mount point (meaning there is something mounted there).  If no such mount point exists then the image file will not be mounted/created.  This will guard against some bug creating the image file in RAM. Btw if you really did want to mount in RAM you could use a path that doesn't start with "/mnt", eg, "/tmp".

Link to comment

Just to potentially confuse the issue some more, I have mine mounted using dlandon's Unassigned Devices plugin and it's working fine...

 

kSH04HP.png

 

Happy to provide logs if anybody thinks they'll be useful..

 

That's why it works.  You have the device mapped to /mnt/ and not /mnt/disks/.  This passes Tom's rules and the docker image will mount because it's not a sub-mount point.  I made a change to UD so this cannot be done any longer when a device mount point is modified.

 

It's not a good idea to mount things in /mnt/ as Tom suggests.  I know Tom is not in favor of UD devices mounting at /mnt/disks/, but I think it is better than users mounting things all over the place.  I enforce the rule that UD devices are mounted at /mnt/disks/ to try to control this.  People were mounting their UD devices all over the place.

Link to comment

Just to potentially confuse the issue some more, I have mine mounted using dlandon's Unassigned Devices plugin and it's working fine...

 

 

Happy to provide logs if anybody thinks they'll be useful..

Actually, that might really help dlandon and Tom simply because you're not using the stock mounts from UD (/mnt/disks)  You've changed it to /mnt/virtualization, and AFAIK every who's failed to get this working was using /mnt/disks, but also afaik you're the first who's got it working who's posted a screenshot.

 

That makes sense because the 2nd component of the path is a mount point - that is what's being checked.  Actually Eric shamed me into doing the proper fix: if the docker (and libvirt) image file path starts with /mnt then we will examine each directory component one-by-one from left to right until we hit a mount point (meaning there is something mounted there).  If no such mount point exists then the image file will not be mounted/created.  This will guard against some bug creating the image file in RAM. Btw if you really did want to mount in RAM you could use a path that doesn't start with "/mnt", eg, "/tmp".

 

I think this is a good solution for those wanting to use UD for docker images.

 

Btw, VMs can be put on a UD mounted device now.

Link to comment

Btw if you really did want to mount in RAM you could use a path that doesn't start with "/mnt", eg, "/tmp".

 

UD does not allow this.  It insists all UD mounted devices be mounted at /mnt/disks/to keep people from mounting devices in inappropriate places - like ram.

 

Dan, I've managed to mount it at /mnt/virtualisation/

 

I thought I did that purely through UD but I may have made some manual changes, it's been so long ago I can't remember...  ???

Link to comment

Btw if you really did want to mount in RAM you could use a path that doesn't start with "/mnt", eg, "/tmp".

 

UD does not allow this.  It insists all UD mounted devices be mounted at /mnt/disks/to keep people from mounting devices in inappropriate places - like ram.

 

Dan, I've managed to mount it at /mnt/virtualisation/

 

I thought I did that purely through UD but I may have made some manual changes, it's been so long ago I can't remember...  ???

 

UD allowed that some time ago, but I implemented a check that prevents that a while back.  If you try to change the mount point name, UD will force it to /mnt/disks/.

Link to comment

How should the wording of the Additional Upgrade Advice be changed?

 

For 6.2 a docker image cannot be on a UD device.  CHBMB managed to make it work because he had a setup from a long time ago that UD allowed, but does not allow any longer.  If he tries to change the mount point name, his configuration will no longer work.  Sounds like LT will implement a fix in an upcoming version.

Link to comment

Oh, may I ask why?

 

Sent from my LG-H815 using Tapatalk

 

Several resons.  One is mounting devices at /mnt/ is not a good idea.  Tom mentioned that earlier.  People were also mounting devices all over the place and it was very difficult to support.  I was constantly asked why a person couldn't find their mounted device because they mounted it in a strange place.  This way devices are always at /mnt/disks/.  There are also some reasons for the powerdown plugin in unmounting array devices.  If a user mounts a device at /mnt/diskX.  Is that an array disk or a UD disk?  The powerdown plugin unmounts all /mnt/disk[!s] which unmounts all /mnt/disk1...29 except /mnt/disks/.  This makes the code a lot cleaner.

 

What difference does it make to you as long as the device is mounted?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.