Weird behaviour with docker on omv4 on orange pi pc2

    • OMV 4.x
    • Resolved
    • Weird behaviour with docker on omv4 on orange pi pc2

      So im runing 4.0.16-1 arrakis on a orange pi pc2 and its working perfectly, no idea if it matter at all but i installed omv3 with the specific image for this model then updated to 4 with omv-release-upgrade and everything went super fine, the system started without error, started samba, did some shares, the hdd works perfectly on a good speed given the device and hdd limitations etc but one i started to use docker i started with weird problems, about half of the dockers containers i try do not work, and i know i need to use either armhf or arm packages, as example Pihole works like a charm same with qbittorrent, both are setup the same, im even using the same macvlan i set up on the pihole guide, but when i tried several others the containers start and SEEM to work exept that i get connection refused on the assigned port, the containers even create the needed config files and folders in the assigned places but i cant see the ui no matter what i do, the must weird thing is that the chocho qbittorrent mentioned before works without any issue but this qbittorrent container DO NOT WORK no matter what i do or set up on the network part or even including those PUID and PGID values for the user i used to create the folders (i tried anything but again, the containers run perfectly and also they create their needed config files with or without the ID values), im totally lost here, can anyone help me here? my knowledge on docker and linux is heavily limited, any help is totally appreciated as i cant find any sonarr/radarr containers that work on this setup.

      TLDR: some docker containers give connection refused on the web UI while others work perfectly, even if the same app.

      PS: just installed nzbget and also seem to work perfectly atm

      The post was edited 1 time, last by Trash_Can_Man ().

    • In fact these are my first steps on both omv and dockers, i wanted a cheap low power option to downloads overnight or even 24/7 for entire weeks on occassions, the nas part was an aftertought that seems to fit on the intended use...anyway, i started directly on omv 3.0 to 4.0 to be directly up to date, as you say this is a very small device but also its not so small to not be able to run some p2p and download apps and maybe some basic media center app like plex or something like that, im not using the device for anything else, its not in a desktop environment at all...and dont take me wrong, im not complaining at all, its free piece of software that works wonderfully on a weak device, when i install dockers on it i TOTALLY know that im pushing the limits allready, i just wanted some pointers to understand what can i be doing wrong...im going to read your links and try again the containers im missing, up to this point i have runingin dockers: pihole, syncthing and nzbget up to date and qbittorrent very outdated but working but with some weird permissions problems not related to the OP...
      Again thanks for any and all tips/help
    • Weird behaviour with docker on omv4

      Link your thread in this post:

      Docker GUI plugin now stable

      Maybe one of the devs @nicjo814 or @subzero79 of the docker gui plugin can help you.

      Greetings Hoppel
      ---------------------------------------------------------------------------------------------------------------
      frontend software - tvos | android tv | libreelec | win10 | kodi krypton
      frontend hardware - appletv 4k | nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2
      -------------------------------------------
      backend software - debian | openmediavault | latest backport kernel | zfs raid-z2 | docker | emby | unifi | vdr | tvheadend | fhem
      backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x10tb wd red | digital devices max s8
      ---------------------------------------------------------------------------------------------------------------------------------------
    • My problem seem to be network related but i can totally try this:


      flmaxey wrote:

      (Don't "pre-create" the folder on the host side - this would apply permissions from the default create mask. Allow the Docker container configuration to create the folder and assign permissions. On the other hand, given the restrictions imposed when working inside a Docker container, it might be best to map to an inside folder that already exists.)


      with the qbittorrent where i have problems changing the settings, they simply dont stay...(tho the weird thing is that the container DO create the default config file when first started if i delete it)
    • Had similar problems with several deluge versions then i decided to try with the good old transmission and this one: Transmission finally worked correctly without issues allways using the macvlan i created for pihole...with deluge i had the weirdest behavior ive seen so far, several containers guides strongly suggest to use host networking but i was unable to reach the daemon on host, on macvlan at least i was able to connect to the daemon but there where permission problems when the daemon was about to write on disk, allmost as if the daemon was runing as a different user...
      Anyway, updating just in case someone else try omv4 with docker on arm and need any of the same containers...thanks and i still cant find any radarr/sonarr container that work, any tip is greatly appreciated...
    • I'm afraid I don't have any arm boxes to play with so I can't test these images you are having issues with.

      However I might have some ideas on how to fix your issues...

      First try to run one of the "problem images" without mapping any volumes inside it. This should take care of any issues regarding permissions. If it starts and you can access it then you most likely had som permission issues.

      Next I would try to make sure that all other containers are stopped before testing (i you are low on resources).

      If it still doesn't work it might be a good idea to run "docker logs -f <name_of_the_container>" after having started a container to see if you can spot any errors.

      Finally make sure that the IP you are assigning the container is actually within the macvlan network you have defined.
    • As example this radarr container gives me some VERY nasty errors, im not very versed in linux language but smells like architecture problems (maybe?):

      Source Code

      1. Stacktrace:
      2. at <unknown> <0xffffffff>
      3. at System.StringComparer..cctor () [0x00000] in <62f5937022004555807e6c57c33f6684>:0
      4. at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) [0x0001f] in <62f5937022004555807e6c57c33f6684>:0
      5. at <unknown> <0xffffffff>
      6. at NLog.Config.LoggingConfiguration..ctor () [0x00001] in <2267be054c0648939ae65b01950a7125>:0
      7. at NzbDrone.Common.Instrumentation.NzbDroneLogger..cctor () [0x00000] in C:\projects\radarr-usby1\src\NzbDrone.Common\Instrumentation\NzbDroneLogger.cs:19
      8. at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) [0x0001f] in <62f5937022004555807e6c57c33f6684>:0
      9. at <unknown> <0xffffffff>
      10. at NzbDrone.Console.ConsoleApp..cctor () [0x00000] in C:\projects\radarr-usby1\src\NzbDrone.Console\ConsoleApp.cs:12
      11. at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) [0x0001f] in <62f5937022004555807e6c57c33f6684>:0
      12. /proc/self/maps:
      13. 00010000-0027e000 r-xp 00000000 00:14 10421 /usr/bin/mono-sgen
      14. 0028d000-0028e000 r--p 0026d000 00:14 10421 /usr/bin/mono-sgen
      15. 0028e000-00290000 rw-p 0026e000 00:14 10421 /usr/bin/mono-sgen
      16. 00290000-002bc000 rw-p 00000000 00:00 0
      17. 0143c000-014dd000 rw-p 00000000 00:00 0 [heap]
      18. f4cac000-f4cc9000 r--p 00000000 00:14 18809 /opt/radarr/Radarr.Host.dll
      19. f4cc9000-f4dc1000 r--p 00000000 00:14 13214 /usr/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll
      20. f4dc1000-f4ddd000 r--p 00000000 00:14 18777 /opt/radarr/NzbDrone.Common.dll.mdb
      21. f4ddd000-f507b000 r--p 00000000 00:14 13199 /usr/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll
      22. f507b000-f5100000 r--p 00000000 00:14 18767 /opt/radarr/NLog.dll
      23. f5100000-f5121000 rw-p 00000000 00:00 0
      24. f5121000-f5200000 ---p 00000000 00:00 0
      25. f5216000-f5255000 r--p 00000000 00:14 18776 /opt/radarr/NzbDrone.Common.dll
      26. f5255000-f526c000 r--p 00000000 00:14 18811 /opt/radarr/Radarr.exe
      27. f526c000-f526d000 ---p 00000000 00:00 0
      28. f526d000-f53ec000 rw-p 00000000 00:00 0
      29. f53f0000-f5400000 rwxp 00000000 00:00 0
      30. f5400000-f5c00000 rw-p 00000000 00:00 0
      31. f5c00000-f5c01000 ---p 00000000 00:00 0
      32. f5c01000-f6800000 rw-p 00000000 00:00 0
      33. f6808000-f680b000 r--p 00000000 00:14 18810 /opt/radarr/Radarr.Host.dll.mdb
      34. f680b000-f680c000 r--p 00000000 00:14 18813 /opt/radarr/Radarr.exe.mdb
      35. f680c000-f6bc2000 r--p 00000000 00:14 11680 /usr/lib/mono/4.5/mscorlib.dll
      36. f6bc2000-f6bc3000 ---p 00000000 00:00 0
      37. f6bc3000-f73c3000 rw-p 00000000 00:00 0
      38. f73c3000-f73f2000 ---p 00000000 00:00 0
      39. f73f2000-f7402000 rwxp 00000000 00:00 0
      40. f7402000-f7409000 r-xp 00000000 00:14 799 /lib/arm-linux-gnueabihf/libnss_files-2.23.so
      41. f7409000-f7418000 ---p 00007000 00:14 799 /lib/arm-linux-gnueabihf/libnss_files-2.23.so
      42. f7418000-f7419000 r--p 00006000 00:14 799 /lib/arm-linux-gnueabihf/libnss_files-2.23.so
      43. f7419000-f741a000 rw-p 00007000 00:14 799 /lib/arm-linux-gnueabihf/libnss_files-2.23.so
      44. f741a000-f7420000 rw-p 00000000 00:00 0
      45. f7420000-f7427000 r-xp 00000000 00:14 803 /lib/arm-linux-gnueabihf/libnss_nis-2.23.so
      46. f7427000-f7436000 ---p 00007000 00:14 803 /lib/arm-linux-gnueabihf/libnss_nis-2.23.so
      47. f7436000-f7437000 r--p 00006000 00:14 803 /lib/arm-linux-gnueabihf/libnss_nis-2.23.so
      48. f7437000-f7438000 rw-p 00007000 00:14 803 /lib/arm-linux-gnueabihf/libnss_nis-2.23.so
      49. f7438000-f7445000 r-xp 00000000 00:14 793 /lib/arm-linux-gnueabihf/libnsl-2.23.so
      50. f7445000-f7454000 ---p 0000d000 00:14 793 /lib/arm-linux-gnueabihf/libnsl-2.23.so
      51. f7454000-f7455000 r--p 0000c000 00:14 793 /lib/arm-linux-gnueabihf/libnsl-2.23.so
      52. f7455000-f7456000 rw-p 0000d000 00:14 793 /lib/arm-linux-gnueabihf/libnsl-2.23.so
      53. f7456000-f7458000 rw-p 00000000 00:00 0
      54. f7458000-f745c000 r-xp 00000000 00:14 795 /lib/arm-linux-gnueabihf/libnss_compat-2.23.so
      55. f745c000-f746c000 ---p 00004000 00:14 795 /lib/arm-linux-gnueabihf/libnss_compat-2.23.so
      56. f746c000-f746d000 r--p 00004000 00:14 795 /lib/arm-linux-gnueabihf/libnss_compat-2.23.so
      57. f746d000-f746e000 rw-p 00005000 00:14 795 /lib/arm-linux-gnueabihf/libnss_compat-2.23.so
      58. f746e000-f7606000 r--p 00000000 00:14 6629 /usr/lib/locale/locale-archive
      59. f7606000-f76dc000 r-xp 00000000 00:14 752 /lib/arm-linux-gnueabihf/libc-2.23.so
      60. f76dc000-f76ec000 ---p 000d6000 00:14 752 /lib/arm-linux-gnueabihf/libc-2.23.so
      61. f76ec000-f76ee000 r--p 000d6000 00:14 752 /lib/arm-linux-gnueabihf/libc-2.23.so
      62. f76ee000-f76ef000 rw-p 000d8000 00:14 752 /lib/arm-linux-gnueabihf/libc-2.23.so
      63. f76ef000-f76f2000 rw-p 00000000 00:00 0
      64. f76f2000-f770a000 r-xp 00000000 00:14 773 /lib/arm-linux-gnueabihf/libgcc_s.so.1
      65. f770a000-f7719000 ---p 00018000 00:14 773 /lib/arm-linux-gnueabihf/libgcc_s.so.1
      66. f7719000-f771a000 rw-p 00017000 00:14 773 /lib/arm-linux-gnueabihf/libgcc_s.so.1
      67. f771a000-f772b000 r-xp 00000000 00:14 818 /lib/arm-linux-gnueabihf/libpthread-2.23.so
      68. f772b000-f773a000 ---p 00011000 00:14 818 /lib/arm-linux-gnueabihf/libpthread-2.23.so
      69. f773a000-f773b000 r--p 00010000 00:14 818 /lib/arm-linux-gnueabihf/libpthread-2.23.so
      70. f773b000-f773c000 rw-p 00011000 00:14 818 /lib/arm-linux-gnueabihf/libpthread-2.23.so
      71. f773c000-f773e000 rw-p 00000000 00:00 0
      72. f773e000-f7740000 r-xp 00000000 00:14 765 /lib/arm-linux-gnueabihf/libdl-2.23.so
      73. f7740000-f774f000 ---p 00002000 00:14 765 /lib/arm-linux-gnueabihf/libdl-2.23.so
      74. f774f000-f7750000 r--p 00001000 00:14 765 /lib/arm-linux-gnueabihf/libdl-2.23.so
      75. f7750000-f7751000 rw-p 00002000 00:14 765 /lib/arm-linux-gnueabihf/libdl-2.23.so
      76. f7751000-f7756000 r-xp 00000000 00:14 824 /lib/arm-linux-gnueabihf/librt-2.23.so
      77. f7756000-f7765000 ---p 00005000 00:14 824 /lib/arm-linux-gnueabihf/librt-2.23.so
      78. f7765000-f7766000 r--p 00004000 00:14 824 /lib/arm-linux-gnueabihf/librt-2.23.so
      79. f7766000-f7767000 rw-p 00005000 00:14 824 /lib/arm-linux-gnueabihf/librt-2.23.so
      80. f7767000-f77ce000 r-xp 00000000 00:14 784 /lib/arm-linux-gnueabihf/libm-2.23.so
      81. f77ce000-f77dd000 ---p 00067000 00:14 784 /lib/arm-linux-gnueabihf/libm-2.23.so
      82. f77dd000-f77de000 r--p 00066000 00:14 784 /lib/arm-linux-gnueabihf/libm-2.23.so
      83. f77de000-f77df000 rw-p 00067000 00:14 784 /lib/arm-linux-gnueabihf/libm-2.23.so
      84. f77df000-f77f7000 r-xp 00000000 00:14 731 /lib/arm-linux-gnueabihf/ld-2.23.so
      85. f77f7000-f7801000 rw-p 00000000 00:00 0
      86. f7801000-f7802000 rw-s 00000000 00:72 224381 /dev/shm/mono.241
      87. f7802000-f7803000 ---p 00000000 00:00 0
      88. f7803000-f7804000 r--p 00000000 00:00 0
      89. f7804000-f7806000 rw-p 00000000 00:00 0
      90. f7806000-f7807000 r--p 00017000 00:14 731 /lib/arm-linux-gnueabihf/ld-2.23.so
      91. f7807000-f7808000 rw-p 00018000 00:14 731 /lib/arm-linux-gnueabihf/ld-2.23.so
      92. fff63000-fff84000 rw-p 00000000 00:00 0 [stack]
      93. ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]
      94. Native stacktrace:
      95. Debug info from gdb:
      96. mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb
      97. =================================================================
      98. Got a SIGILL while executing native code. This usually indicates
      99. a fatal error in the mono runtime or one of the native libraries
      100. used by your application.
      101. =================================================================
      Display All
    • Similar (if not identical) messages repeat several times each time i start that one (both with and without mappings) and keeps apprearing more every few seconds...its a specific container for armhf so i shouldnt have architecture problems...also i have another 2 armhf containers from lsio so i can kinda trust their origin...



      "docker logs -f container" gives me

      Source Code

      1. Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.35/containers/radarr/logs?follow=1&stderr=1&stdout=1&tail=all: dial unix /var/run/docker.sock: connect: permission denied

      on all my containers (both the ones working fine and the ones that dont), maybe some weird harmless warning?



      Also the dashboard shows 35% memory used stable with the 5 containers that im using atm active at the same time, so i think that i can squeeze a pair more of lightweight ones like radarr and sonarr and the like, and cpu rarely goes over 30% too...



      The ip is correct as i have 5 other containers runing in the same macvlan and every one with a different ip and they all work perfect, i also did a ping when the container is on and i get under 1ms response, so the packets dont seem to be routed weirdly (the ping timeouts when the container is down so i know that its the container that opens that ip)



      Again, remember that i get a connection refused error on the browser and instantly (when the cointainer is up, ofc)



      Last, thanks flmaxey for the link, im reading it slowly as it is a bit complex for me, remember im simply a semi-advanced user, not a coder, im reading ir anyway to see if i can learn something to help with my problem...


      Thanks in advance for any help and sorry i wrote 2 posts in a row, had a problem with the 10000 char limit
    • I just did some extra research and maybe this is loosely related to my problem with radarr/sonarr? i got several other containers in different languages with similar problems tho...

      And now i see that the permissions denied error is because i didnt had access with that specific user, going to try again in a few mins...ok, dumb me, the logs button on the docker interface of omv gives me the same info as if i do manualy "docker logs -f container" on CLI (if i do it with a user with privileges)...

      The post was edited 3 times, last by Trash_Can_Man ().

    • Yea yea after some more research i realized of my mistake and corrected it myself, read my edits on the previous post, basically gives me the same as the code box on my previous post

      One more edit, since uname tells me that this thing is runing in aarch64 i also tried an aarch64 version of radarr too...and JACKPOT!!! its runing, now i need to test if everything works but at least i get the web ui correctly...gonna search for some qbittorrent aarch64 to see if my problem there is related to that too...the weird thing is that in several places states that armhf code should work fine on aarch64 but again, im no coder or dev, im just trying different thing to see if they work...
      At least if this stays in the forum i can help a bit the poor folk that have similar problems on another opi pc2...
      Im going to keep testing things a few hours/days and post again more info or success rate as i keep setting this up...
      Again thanks in advance for any help :D

      The post was edited 2 times, last by Trash_Can_Man ().

    • In fact i was searching by hand only writing the exact name of the application ("radarr" as example) without nothing extra but your idea is a bit more detailed because some containers dont show any architecture in plain but there is several options on the tags as in your pi-hole example...also in your pihole example i just downloaded the main "multiarch" package, im guessing that it auto-detect the system arch and probably there is where my problems started because i assumed that armhf where the better choice overall in my case...in fact im going to move my packages to aarch64 now if i see no problems as it seem more specific for this hardware...

      And once again, very VERY helpfull and thank you :D
    • By the way i have a related question, how do we update the containers? im guessing that most package mechanism is locked inside a container so "apt-get upgrade" or any update mechanism proper to the app in question isnt going to work so i must use the "pull image" button and create a new container i guess? or the system is smart enough so if i pull a new image it also updates the related container without the need to create a new one?

      And some update, the qbittorrent problem was also related to architecture (even if it seemed like permissions problems) now i can write the config file, change my password, change any settings all with the aarch64 version, im so happy i found the solution to my problems... :D

      The post was edited 1 time, last by Trash_Can_Man ().

    • flmaxey wrote:



      Trash_Can_Man wrote:

      By the way i have a related question, how do we update the containers? im guessing that most package mechanism is locked inside a container so "apt-get upgrade" or any update mechanism proper to the app in question isnt going to work so i must use the "pull image" button and create a new container i guess? or the system is smart enough so if i pull a new image it also updates the related container without the need to create a new one?

      And some update, the qbittorrent problem was also related to architecture (even if it seemed like permissions problems) now i can write the config file, change my password, change any settings all with the aarch64 version, im so happy i found the solution to my problems... :D
      First, most Docker Dev's will tell you - DO NOT use an app's internal links to update. That's reasonable in that app's download installers. Docker images are "preinstalled" so there's no upgrade path in the traditional sense. (apt-get commands on the host side have no effect on Docker images or containers.) While some Dockers claim to auto-update, such a feature would be a reason why I wouldn't install it, if I couldn't turn it off.__________________

      This is where I suffer mightily from past experience in datacenters and networking- I am extremely "conservative". (And it's served me well.) :thumbup: With that in mind, now that you're working (with a bit of grief in the process), why would you risk changing anything without testing it first? :thumbdown: What you're suggesting would be the equivalent of finding the right Linux Distro, that works perfectly with your hardware, then allowing some automated process to switch distributions (to something that might not work).

      Here's something to consider - Docker images are not unlike ISO's. Unfortunately, Docker Dev's are not obligated to maintain older images and some don't. So, it's possible that an automated process might delete or alter a working base image and replace it with something that's untested (at best) or doesn't work (at the worst).

      On the other hand, if you want to be on the bleeding edge, here's something that might work for you. -> WatchTower

      What I would suggest, in any case, is clone your boot drive. If your Docker(s) are nuked, you'll be able to fall back to a working build. (And backup is always a good idea.)

      Cheers
      OHHH now i see what do you mean!!! after all its so easy to download another image for a newer version of any app i might use and start a NEW container alongside the old one for a few days for testing im kinda new to dockers so sometimes i dont think of certain use cases as you can see and also i now know why most containers have the option to store the config files externally, to ease on updating!!! And no, im not worried about the bleeding edge, im happy to have most everything updated to 3-6 months old...(and not even because of new features but mostly because of security concerns)

      Also im planning to do a full raw backup of the sd card on the opi once i finish setting everything i want on it correctly...
    • Well yea, thats a bit to much for my use case, im conservative too and im considering starting from scratch but now knowing what to install exactly and how (ergo doing a whole totally CLEAN install) and then do the full backup when its ready but getting a second board just for testing feels a bit to much lol

      The full backup as i mention alleviate the problem of the merging images, in extreme cases i can roll back to the clean backup...your solution is perfect in fact, but the 2nd board ends in a drawer 99% of the time, feels like a waste, even if cheap...
    • Yea thats why i chose this one to be used as NAS, even if it have usb2.0 (giving me about 35-40MBs) its a lot better for a home use than any 100mbit wth board, and also 2 of the usb ports are HOST, no shared bandwidth with the eth either...ofc a better solution is an actual nas solution but this is so cheap that for home use is perfect...
      And i have 2 rpi3 here at home that the kids use to watch youtube and play some retro games, the opipc2 act as a server both for media as for the games lol
      Im also planning to buy an odroid xu4 in a not to distant future for the main tv, but thats another story, i love these small boards as you can see, and tinker with them too xD
    • So a last update about my situation, orange pi pc2 totally need aarch64 architecture dockers, EVERY docker i tested with a tag for aarch64 works perfectly, leaving this last comment here for any future opipc2 owner struggling with this ussue...
      The weird thing about this situation is that most armhf images i tested ran perfectly according to the docker ui, most dont even gave errors, but i was getting "connection refused" when i tried to connect to their web UIs instead of plainly not working...
      Cya and thanks for watching...
    • flmaxey wrote:

      Since this is your thread:

      If you can, maybe you should insert orange pi pc2 and/or O-PI PC2 in the thread title. Also, it wouldn't hurt to add them as tags, along with the resolved tag. If someone comes looking, you might save them some grief.
      Just saw your tags and title suggestion and did the corrections...also...im still having random problems and instability with dockers that include any form of MONO, apparently MONO is super unstable on aarch64 platforms, just so anyone else wanders in this topic with similar problems, probably they are gonna get fixed in the future when the h5 chipsets have better support...i think this is related but again im not not an expert so im not sure: mono arm64
      Going back to the first post some examples of mono based software that maybe someone will want to run on dockers: radarr, sonarr, jackett, emby.
      You can replace sonarr with sickbeard and maybe emby with some kodi-headless (since plex is not an option either)...
      Again thanks anyone for watching hopefully i save someone else with an opipc2 some time otherwise wasted searching and trying