docker files not working, but status is up and running.

johnnyNormal · Nov 10th 2023

Hi,

I am trying to install sonarr and radarr (among others, but we'll start there), I m following the guide in OMV-extras (here) on getting docker set up. It looks to be up and running and I am at more or less the final step of installing jellyfin (sonarr in my case).

I am creating a file from example in compose, and it creates fine, shows status as down, and when I hit up, I get the following error:

Code

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker compose --file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/sonarr/sonarr.yml' --env-file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/sonarr/sonarr.env' --env-file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/global.env' up -d 2>&1': Couldn't find env file: /srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/sonarr/sonarr.env

OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker compose --file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/sonarr/sonarr.yml' --env-file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/sonarr/sonarr.env' --env-file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/global.env' up -d 2>&1': Couldn't find env file: /srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/sonarr/sonarr.env in /usr/share/openmediavault/engined/rpc/compose.inc:693
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(620): OMVRpcServiceCompose->{closure}('/tmp/bgstatus2b...', '/tmp/bgoutputcE...')
#1 /usr/share/openmediavault/engined/rpc/compose.inc(696): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
#2 [internal function]: OMVRpcServiceCompose->doCommand(Array, Array)
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('doCommand', Array, Array)
#5 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('Compose', 'doCommand', Array, Array, 1)
#6 {main}

Display More

the path in export PATH=.... seems strange to me, but I have no frame of reference so hopefully this thread can shed some light on that. the same goes for radarr. the same error occurs on a straight docker pull (via the OMV UI).

One thing to note is that every time I open compose settings, I am asked to confirm changes, and they a are approved every time, but no changes have technically been made. I am not sure if this is adding to the issue or something different (after approving the changes, the above error still occurs).

Below are some screenshots of the shared folders and then the compose config.

Technical info:

OMV Version 6.9.7-1 (Shaitan)

Processor ARMv7 Processor rev 4 (v7l)

Kernel Linux 6.1.21-v7+ Running on a Raspberry pi 3

I am not sure what other info might be needed but just ask and I will add it to the thread.

TIA.

raulfg3 · Nov 10th 2023

change user: group from root:root to something like dockeruser:user (you need to create user dockeruser in webUI with enougt privileges to access your shared folders)

and select to permit read&write to users:

actually only owner have permission

and finally use button reinstall docker.

this time must work

johnnyNormal · Nov 10th 2023

Quote from raulfg3

change user: group from root:root to something like dockeruser:user (you need to create user dockeruser in webUI with enougt privileges to access your shared folders)

and select to permit read&write to users:
actually only owner have permission

and finally use button reinstall docker.

this time must work

Display More

Hey, thanks for the quick reply. I had a user created already created from the pi, and used that (it has the necessary perms), I am now getting this error:

Code

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker compose --file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/radarr/radarr.yml' --env-file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/radarr/radarr.env' --env-file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/global.env' pull 2>&1':  radarr Pulling
no matching manifest for linux/arm/v7 in the manifest list entries

OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker compose --file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/radarr/radarr.yml' --env-file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/radarr/radarr.env' --env-file '/srv/dev-disk-by-uuid-bd50ca6f-7f69-4327-aeee-c8ad38004db4/appdata/global.env' pull 2>&1':  radarr Pulling
no matching manifest for linux/arm/v7 in the manifest list entries in /usr/share/openmediavault/engined/rpc/compose.inc:693
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(620): OMVRpcServiceCompose->{closure}('/tmp/bgstatusoq...', '/tmp/bgoutputUX...')
#1 /usr/share/openmediavault/engined/rpc/compose.inc(696): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
#2 [internal function]: OMVRpcServiceCompose->doCommand(Array, Array)
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('doCommand', Array, Array)
#5 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('Compose', 'doCommand', Array, Array, 1)
#6 {main}

Display More

Doing some research on "no matching manifest for linux/arm/v7 in the manifest list entries" means that no docker image for sonarr exists that isn't compatible with the architecture of the pi? I am running rasbian OS lite to keep the footprint of the pi as small as possible for the nas.

raulfg3 · Nov 10th 2023

you need to use a image compatible with your architecture , search on dockerhub: https://hub.docker.com/search?q=sonarr

revise that your OMV install on pi is 64bit, because all dockerhub images are for arm64.

johnnyNormal · Nov 10th 2023

Quote from raulfg3

you need to use a image compatible with your architecture , search on dockerhub: https://hub.docker.com/search?q=sonarr

revise that your OMV install on pi is 64bit, because all dockerhub images are for arm64.

Display More

welp, I wasn't aware of the 64 bit side of things. my pi is running 32 bit arch so I can only presume that OMV is running 32bit also. Is there a way to confirm this?

johnnyNormal · Nov 10th 2023

stupid question above, I've just started on a 64bit os install. Will start from scratch and go from there.

johnnyNormal · Nov 10th 2023

Just an FYI if anyone comes across this in the future, installing the 64bit arch combined with what raulfg3 said above fixed the issue.

mikewazowski · Nov 16th 2023

Did you have to reinstall and reconfigure everything after a fresh install or could you restore from a backup?

I'm using an SSD as a boot drive which also provides space for docker and trying to figure out how to update to arm64 without nuking everything...

macom · Nov 16th 2023

Thread

[How to] Backup and Restore OMV Configuration with omv-regen

DO YOU NEED TO BACKUP OR RESTORE THE OMV CONFIGURATION?

THIS IS THE SOLUTION.

Si quieres leer todo esto en español puedes hacerlo en github

OMV-REGEN

INSTALLATION:

Copy and paste the following line into a terminal and run it as root or with sudo.

sudo wget -O - https://raw.githubusercontent.com/xhente/omv-regen/master/omv-regen.sh | sudo bash

STEP 1. Create a backup of the original system with omv-regen.
STEP 2. Do a fresh installation of OMV on the disk you want and connect the data drives.
STEP 3. Use…

chente

Apr 29th 2023

mikewazowski · Nov 18th 2023

Quote from macom

Thread

[How to] Backup and Restore OMV Configuration with omv-regen

DO YOU NEED TO BACKUP OR RESTORE THE OMV CONFIGURATION?

THIS IS THE SOLUTION.

Si quieres leer todo esto en español puedes hacerlo en github

OMV-REGEN

INSTALLATION:

Copy and paste the following line into a terminal and run it as root or with sudo.

sudo wget -O - https://raw.githubusercontent.com/xhente/omv-regen/master/omv-regen.sh | sudo bash

STEP 1. Create a backup of the original system with omv-regen.
STEP 2. Do a fresh installation of OMV on the disk you want and connect the data drives.
STEP 3. Use…

chente

Apr 29th 2023

Thank for this. I've tried to follow this process to upgrade to Raspberry Pi OS 64-bit using a new SD card but have run into an issue trying to restore the backup created with omv-regen:

All the redacted data drives match, but the last one does not match. Does this refer to the SD card? Is it considering the SD card as a data drive? I'm using a new SD card as the guide suggests so I don't overwrite the existing install in case the renegeration fails.

There could be something else wrong with my configuration though so I appreciate any suggestions.

Edit: Running omv-regen using the original SD card shows this, which confirms those are references to the SD cards:

However it still shows the error "The information from the system unit could not be read."

Does this suggest omv-regen is treating the SD card as a data disk and not a system disk? Or perhaps it is related to partitions?

chente · Nov 18th 2023

Quote from mikewazowski

I've tried to follow this process to upgrade to Raspberry Pi OS 64-bit using a new SD card but have run into an issue trying to restore the backup created with omv-regen

Fixed in version 2.0.3

mikewazowski · Nov 20th 2023

Quote from chente

Fixed in version 2.0.3

Thanks very much! This worked for me in the end.

I ran into an issue where all of my data drives were disconnecting and I thought may have been caused by omv-regen, but turns out it was an issue with UAS and one of the data disks which is an SSD in an external enclosure (more info here). I had previously fixed this by editing /boot/config.txt but obviously the fresh OMV install reset this.

I did have to reinstall the compose plugin and I'm not sure why as the guide says this will be restored. This wasn't a big issue as once I reinstalled the plugin Portainer was as it was before the upgrade and did not need to be restored from a backup (as recommended the docker installation path was on one of the data disks).

I also still had this error in omv-regen even though all the data disks were connected and present in the list, just not in the same order (but this didn't prevent me from executing the regeneration):

These were the steps I followed if anyone else needs to upgrade to 64-bit so certain containers will still receive updates:

Backup existing installation using omv-regen and transfer backup via WinSCP
Install Raspberry Pi OS (Legacy, 64-bit) Lite on new SD card
Shutdown existing server and disconnect data drives and remove SD card
Insert new SD card into system, connect via SSH and install OMV using install script from wiki
Shutdown system, reattach data drives and restart system
Transfer omv-regen backup to system drive (SD card) via WinSCP
Install omv-regen and restore backup
Reconnect and confirm working
Reinstall compose-plugin

chente · Nov 20th 2023

Quote from mikewazowski

I did have to reinstall the compose plugin and I'm not sure why as the guide says this will be restored. This wasn't a big issue as once I reinstalled the plugin Portainer was as it was before the upgrade and did not need to be restored from a backup (as recommended the docker installation path was on one of the data disks).

I'll check this out. I don't see why installing the compose plugin shouldn't work. In any case, I'm glad you solved it.

Quote from mikewazowski

I also still had this error in omv-regen even though all the data disks were connected and present in the list, just not in the same order (but this didn't prevent me from executing the regeneration):

Do you have any data drives with a special format?

It is difficult to detect all possible units, that is why I did not want to prevent regeneration from being carried out under these conditions and I limited myself to placing a red warning if that case occurs.

chente · Nov 22nd 2023

Quote from mikewazowski

I did have to reinstall the compose plugin and I'm not sure why as the guide says this will be restored.

Fixed in omv-regen 2.0.4

mikewazowski · Nov 22nd 2023

Quote from chente

Do you have any data drives with a special format?
It is difficult to detect all possible units, that is why I did not want to prevent regeneration from being carried out under these conditions and I limited myself to placing a red warning if that case occurs.

I don't think so, all the drives are WD drives with EXT4 filesystems.

Quote from chente

Fixed in omv-regen 2.0.4

Thanks for this also. I realised too late that this may have actually been my error - I think I mistakenly uninstalled sharerootfs plugin before running the regen, which I read would have also removed the compose plugin (so apologies if I sent you looking for a non-existent bug).

Unfortunately I've had stability issues since the migration. I think I've narrowed it down to an issue with logging, as when I inspect the syslog via SSH (cat /var/log/syslog) I can sometimes see the cpu usage (via htop) growing to 100% in several seconds before the system freezes and crashes. This also happens when inspecting docker container logs via Portainer, so I have avoided the problem for now by uninstalling Portainer and using the compose plugin to manage containers (have had no issues inpsecting logs with the plugin).

This issue may be specific to my setup or unrelated to omv-regen so I wouldn't want to suggest it was caused by the regeneration. If the issue persists I may have to do a fresh install of OMV and rebuild manually.

chente · Nov 22nd 2023

Quote from mikewazowski

I don't think so, all the drives are WD drives with EXT4 filesystems.

This may be related to connecting the drives via USB. Raspberries are a world apart. I'll take a look at it anyway but I don't have USB enclosures to connect drives to a Raspberry, so it will be difficult for me. When you have time to look at it, it may ask you to output a command.

Quote from mikewazowski

Thanks for this also. I realised too late that this may have actually been my error - I think I mistakenly uninstalled sharerootfs plugin before running the regen, which I read would have also removed the compose plugin (so apologies if I sent you looking for a non-existent bug).

No. That was my mistake. Some previous changes caused compose to not install, it is now reverted.

Quote from mikewazowski

Unfortunately I've had stability issues since the migration. I think I've narrowed it down to an issue with logging, as when I inspect the syslog via SSH (cat /var/log/syslog) I can sometimes see the cpu usage (via htop) growing to 100% in several seconds before the system freezes and crashes. This also happens when inspecting docker container logs via Portainer, so I have avoided the problem for now by uninstalling Portainer and using the compose plugin to manage containers (have had no issues inpsecting logs with the plugin).

This issue may be specific to my setup or unrelated to omv-regen so I wouldn't want to suggest it was caused by the regeneration. If the issue persists I may have to do a fresh install of OMV and rebuild manually.

That's weird. omv-regen only reproduces from the CLI the actions that are executed in the GUI following a logical configuration order based on the original database. There were some important changes in version 2 by adding a GUI for omv-regen, but the underlying machinery has remained the same for a long time, that has not changed. Maybe if you could give more details we could know what the problem is.

docker files not working, but status is up and running.

johnnyNormal Nov 10th 2023

chente Nov 10th 2023

chente Nov 11th 2023

Participate now!

Similar Threads

Docker in LXC with kvm plugin AppArmor issue

After upgrade from 5 to 6 strange docker behavior and old machines show up that i thought were gone

Docker doesn´t start after last upgrade to 5:23.0.0-1~debian.11~bullseye

mail notification

docker not working since omv-upgrade

DNS resolution issue