Posts by lockerlab

    Recently, I switched to OMV 7 and I'm very happy with all the enhancements and the stability of the system. The changes to Docker management are also great, namely going with a native plugin. Thank you!


    One thing, that currently doesn't work though, is the memory stats in the Compose-plugin Stats section (see below). Is there any further setup needed to see how much memory my containers consume?


    I'm running OMV7 on Raspberry Pi OS 64-bit. Reading the memory stats under Diagnostics -> Processes works as expected.

    With help from the Posteo support team (thanks!) I was able to sort out this issue:


    mail.posteo.de that was mentioned above was never used as an SMTP relay, it was rather a redirection to posteo.de. This subdomain hasn't been in use for some time now. When using posteo.de instead, Postfix would try an MX lookup and in return receive a timeout for mx0*.posteo.de which is not meant for sending e-mails.


    What resolves this issue, is setting posteo.de in square brackets as the SMTP server, thereby disabling MX lookup (see: https://www.postfix.org/postconf.5.html#relayhost).

    Why are you making a shared folder on docker folders?

    This was the original set-up that worked until recently (but I'm unsure why I created the folder in that way in the first place). When trying out different solutions, I also let the omv-extras Docker interface create this folder, which, as I understand, is the preferred way (besides using docker from the command line). Unfortunately hasn't solved the issue though.

    Code: ls -la /var/run/docker
    total 0
    drwx------  8 root root  180 May 22 23:15 .
    drwxr-xr-x 30 root root 1160 May 22 23:15 ..
    drwxr-xr-x  3 root root   60 May 22 23:15 containerd
    drw-------  2 root root   60 May 22 23:15 libnetwork
    srwxr-xr-x  1 root root    0 May 22 23:15 metrics.sock
    drwxr-xr-x  2 root root   60 May 22 23:15 netns
    drwx------  2 root root   40 Apr 29 19:03 plugins
    drwx------  3 root root   60 Apr 29 19:03 runtime-runc
    drwx------  2 root root   40 Apr 29 19:03 swarm


    I didn't dare to try the mount remount solution, didn't want to mess things up further. But if it's unproblematic, I might give it a go

    Thank you so far!


    After going through steps 1-4, the mentioned error still prevents me from deploying stacks :/ It also persists when deleting the /docker directory in Access Rights Management | Shared Folders, re-adding it through the GUI, as well as trying a new directory with a completely different name.


    Could this then be related to something else than directory permission issues? I am certain that I only changed the permissions on /srv/dev-disk-by-label-wdred1/ and not elsewhere.

    Alright, in that case I would go for a fresh install, I think. I'm positive about the backups, just tried importing them into other instances of the respective apps and it worked well.


    How would I go about doing a fresh install? This is how I'd imagine it to go:

    1. Remove Portainer, then Docker through OMV GUI
    2. rm -rf /srv/dev-disk-by-label-wdred1/docker/
    3. mkdir /srv/dev-disk-by-label-wdred1/docker/, then check symbolic link from /var/lib/docker to said directory
    4. Install Docker, then Portainer through GUI
    5. Set up new Docker containers, this time setting their config path to another directory then the docker root

    Would this work or am I reintroducing problems that I had before?

    Regarding the config of running containers: What do you mean by that?

    - docker-compose.yml + .env files

    - the volumes where the containers store their data?

    I have backed up the compose files, but also the docker apps as recommended in the respective docs (be it database dumps or config jsons). Not that I know whether that would be helpful, but I had also been backing up the /docker path - I haven't backed up volumes as described here: https://docs.docker.com/storag…e-or-migrate-data-volumes

    What didn't fit into previous code block

    Thanks for following up! Here is the output of the commands:


    (only bookstack+db, duplicati and heimdall had been running

    tl;dr: After setting permissions (wrongly), stacks can't be created or removed in Portainer (log: docker-compose: permission denied)


    Hi all,


    Recently, after adding a new drive to a MergerFS union, I noticed that Jellyfin (running in Docker) was not able to see media stored on the newly added drive. Before that, I had updated the volumes in docker-compose (through Portainer stack) to point to the desired location in the MergerFS-union, so I figured that this was a permissions issue. To solve this, I messed with the ACL and permissions in the OMV GUI, but this didn't help.


    Today, while trying to update my Docker containers, Portainer started throwing the following error: failed to remove a stack: unknown shorthand flag: 'f' in -f (similar to: https://github.com/portainer/p…ues/6069#issue-1052081903) as well as failed to fetch metadata: fork/exec /data/docker_config/cli-plugins/docker-compose: permission denied.

    Additionally, Duplicati (run in Docker) now throws the following error when starting a backup job: Access to the path "/tmp/dup-190b2edd-5d3e-4568-b970-ddd91144b744" is denied.


    To mitigate this, I tried to remove and re-install both Docker and Portainer through the OMV GUI (this was also the only way I installed them before), but it hasn't changed anything as well.


    Because of the "permission denied"-errors, I suspect that I messed up Docker-path-related permissions. I found the following issues, but don't know how to apply them to my specific situation:

    I'd be happy about any suggestions to fix this issue. Thanks!

    failed to remove a stack: unknown shorthand flag: 'f' in -ffailed to remove a stack: unknown shorthand flag: 'f' in -