General Problem with Docker and Sharedfolders

  • I use docker and portainer rather intensely on omv managing a bunch of crap. I structure most of the containers to have configs in one sharedfolder and content in another and map to those so really the only thing the container has locally is itself, so I can cycle em out and backup the configs and such to another storage on their own. This is helpful for plex cause it's a hog with its config dir so that goes on a faster drive separate from a larger media pool which is also on its own drive.


    Anyway, the issue I'm having and this has surfaced a few times is that if the sharedfolders for whatever reason, maybe on boot? aren't available to the containers in time, the containers will write to the path /sharedfolders/stuff, and then even if the sharedfolders gets mounted right after, the app is writing underneath, then the disk fills up and OMV interface isn't accessible, and my / volume is full. Then I have to reboot, comment out the two drives that were mapped to these shares, delete the content that was written to the real / path on the local disk, and reboot the instance.


    I'm not sure why in all the cases this has happened but I'm thinking maybe this isn't the best way, using sharedfolders, for docker like this but i'm not really sure about how to do this as an alternative. If I can mount a new disk somewhere else that guarantees it won't mount it if the disk isn't available, perhaps that's the right way, just not sure off the top of my head that's any different than what the shared folders is doing.


    How do the sharedfolders map to the device? It seems like some hybrid between mounting and symlinking but i'm not familiar with how they work.


    Maybe I should just write to the full /srv/dev-disk-xyz-0123 path?


    Even in the time I wrote this, had to restart some containers after reboot, some of the underlying fs filled up"


    before


    Code
    /dev/sda1 98730 5293 88404 6% /


    a little later I think after I restarted the containers



    Code
    /dev/sda1 98730 74283 19414 80% /


    Is there a way to delay the docker service from starting until the end of the boot up cycle?

    Proxmox Cluster with OMV 5x on KVM
    OMV 5.0.10-1
    Containers, Containers, Containers

    Edited once, last by seed ().

  • So this seems to be the issue, docker starting before the sharedfolders are mounted:


    Code
    2020-02-17T22:05:22-0800 omv.humptydance.nope dockerd[721]: time="2020-02-17T22:05:22.517570335-08:00" level=info msg="Starting up"
    2020-02-17T22:05:32-0800 omv.humptydance.nope systemd[1]: sharedfolders-apps.mount: Directory /sharedfolders/apps to mount over is not empty, mounting anyway.

    Proxmox Cluster with OMV 5x on KVM
    OMV 5.0.10-1
    Containers, Containers, Containers

  • I have the same issue, tried the fix forum.openmediavault.org/index…V5-Pi4-This-might-fix-it/ but I think in my case it was related with hd-idle spinning down the drive where files from sonarr are downloaded. I noticed in omv ui that hdd where files are downloaded would get different mapping , e.g. /dev/sda1 then /dev/sdb1 etc. it resulted in the same effect as decribed by OP. I now disabled hd idle, but can someone help me get hd-idle configured and this issue solved?

  • If you are using /sharedfolders/.......... paths in your docker Volume and Bind Mounts you are making a mistake. Use the actual location of the folders instead.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • If you are using /sharedfolders/.......... paths in your docker Volume and Bind Mounts you are making a mistake. Use the actual location of the folders instead.

    I've actually mounted volumes by absolute bath (/dev-disk-by-label) but still the filesystem on the HDD unmounts itself, when I mount it manually I get en error:


    kernel: [54710.861585] EXT4-fs error (device sda1): ext4_find_entry:1455: inode #1835042: comm Plex Media Serv: reading directory lblock 0


    in general, the re-mounted filesystem has different path (sdx) and containers can't seem to find it.


    the main problem is why my HDD gives clicking sounds and then umounts itself? I tried various power adapters (I have additional power for this drive)

  • You might have a failing drive it it makes clicking noises. Your drives should be mounting via UUID or Disk Label, but not by /dev/sdx.


    If you are using USB drives, you are likely going to have problems.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • You might have a failing drive it it makes clicking noises. Your drives should be mounting via UUID or Disk Label, but not by /dev/sdx.


    If you are using USB drives, you are likely going to have problems.

    thanks. I have two 2.5'' drives, HDD and SSD both attached via USB 3.0 ports on the Pi 4. They are mounted in fstab via disk label, but for some reason in the OMV inteface I can see /dev/sdx (attached). SSD does not have external power, HDD has as it was failing to operate without it.


    How else can I use hard drives?


    [edit]
    I don't think the drive is failing as it operates normally otherwise, I also run a few test and plugged it to my windows PC. There is something that my pi does not like about this drive. I should add I'm powering the HDD with additional power source, bcause when I don't the drive is not operating properly. I also tried a few power sources and the behavior is more or less consistent, i.e. it tends to dissapear. What's interesting is that it can surive a reboot or two, and sometimes I need to power down the OMV and then on and only after that the drive comes back to be visible.


    When I lose the HDD I get this error in syslog: usb2-port2: Cannot enable. Maybe the USB cable is bad?, but the cable works fine. I don't have another to test though

  • If you are using /sharedfolders/.......... paths in your docker Volume and Bind Mounts you are making a mistake. Use the actual location of the folders instead.

    Sorta the point though shared folders. Why go digging for the srv disk ID really..... It's annoying. Why can't they just fix it so that docker spins up after the drives and sharedfolders routine is done...


    @'wookash 'Go start a different thread please....

    Proxmox Cluster with OMV 5x on KVM
    OMV 5.0.10-1
    Containers, Containers, Containers

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!