Docker is renaming a mounted drive [Solved]
from gedaliyah@lemmy.world to selfhosted@lemmy.world on 14 Jun 09:36
https://lemmy.world/post/31370604

So I recently moved most of my docker storage to a second hard drive, called “storage.” After a system restart, docker is creating a folder called “storage,” forcing the physical drive to be renamed “storage1.” How do I prevent this from happening?

I am using Xubuntu.

Edit: As suggested, it was indeed my system spinning up Docker before mounting the internal disk. The solution (should work on most Unix-like systems) was to manually add a line to /etc/fstab as follows: First get the UUID for the problem drive

~$ sudo blkid -s UUID

The output will show your drives and the UUID of each. Then edit the following file:

~$ sudo mousepad /etc/fstab #{or use your choice of editor, i.e. nano}

Add the following line:

/dev/disk/by-uuid/{UUID number copied from blkid output} /destination/of/your/drive ext4 defaults 0 0

Of course replace {UUID number copied from blkid output} and /destination/of/your/drive and set defaults & parameters as needed. These worked for me.

Restart the system and the drive should be forced to mount before docker starts. This seems to be a known issue with certain docker setups.

#selfhosted

threaded - newest

walden@sub.wetshaving.social on 14 Jun 09:59 next collapse

I’m not an expert, but I think we need more information.

gedaliyah@lemmy.world on 14 Jun 10:41 collapse

I’m even less of an expert lol. What information can I provide to help?

towerful@programming.dev on 14 Jun 10:56 collapse

The commands you used to start the docker containers, or the docker compose contents.
That’s what dictates how much “power” a docker container has

SpatchyIsOnline@lemmy.world on 14 Jun 10:21 next collapse

It sounds to me like one (or more) of your containers is referencing something on your storage drive, but Docker is loading before your drive gets mounted. When Docker sees that the folder its trying to access doesn’t exist, it creates it, blocking your drive from taking that name.

To fix it, you would need to make sure your storage drive is mounted before Docker starts, how you do that is down to you and your particular setup though.

friend_of_satan@lemmy.world on 14 Jun 11:08 collapse

That’s a good theory. This may be able to be investigated further with systemd-analyze plot > boot.svg

i_stole_ur_taco@lemmy.ca on 14 Jun 10:48 next collapse

Is Docker starting up and one of the containers mounts a volume to a /storage folder on the host? That could explain it but I’m not super clear on all that’s going on in your system.

Quick test: disable auto start on all your containers and restart and see if it recurs.

gedaliyah@lemmy.world on 14 Jun 11:00 collapse

I believe that’s exactly what is happening. I just don’t know how to fix it. I could edit the YML files and delete restart: unless-stopped but I want my containers to restart if something goes down unexpectedly

i_stole_ur_taco@lemmy.ca on 14 Jun 12:59 collapse

So is the issue that your extra drive mounts to /storage, but that happens after Docker has already started and taken over the directory, so the mount fails? Normally I’d expect it to happen in the other order. Is this a weird race condition?

This might be a good thing to run through with ChatGPT- there are probably ways to delay the Docker container start, but maybe there’s a more significant misconfiguration you can deal with.

bus_factor@lemmy.world on 14 Jun 12:32 collapse

It looks like you’re relying on media automounting to access the drive, but this is happening too late for Docker.

I would suggest creating the empty folder and explicitly adding the mount to /etc/fstab instead. This should mount early enough, and even if it doesn’t it needs an empty folder for the mount point anyway.

Edit: Make sure you reference the partition by UUID, because the device name of USB devices sometimes change after a reboot.

scrubbles@poptalk.scrubbles.tech on 14 Jun 15:08 next collapse

Agreed. Needs to be a required mount in fstab. System won’t even start then if the mount fails, docker always has access

gedaliyah@lemmy.world on 15 Jun 14:48 collapse

Thanks - this was the solution. I’ve updated the post to reflect the solution I used.