Weird behaviour with docker on omv4 on orange pi pc2

    • OMV 4.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • 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 ().

    • First, I don't know the development state of OMV 4 or the Docker plugin that's paired to it, but it seems like you have a lot going on in the way of networked Dockers.
      While not recommended by the image Dev' of Pi-hole, the macvlan driver was used to make a separate IP address (and port 80) available to the pi-hole container without conflicting with OMV's console. (In this case, Pi-hole needed port 80 to be 100% functional.) With that noted, I don't know how many individual IP addresses a macvlan driver will support. It stands to reason that the number of IP addresses would be limited.

      When setting up a Docker, understanding which mode to use is useful - Host mode is best if the applications' ports don't conflict with the host. Bridged mode can be used when exposed ports can be remapped to host ports. ((There are a couple other methods that I have yet to try such as Open vSwitch bridge and even a twist on NAT. Info -> Connect Dockers))

      Then there's working with the images/containers themselves as different Dev's have differing approaches. Some app's will never work well in a Docker (such as Netdata) and even when they can, all Dockers are not created equal. I'm finding that even among the best constructed and supported Dockers (linuxserver.io), a "tweak" of some kind is usually needed.

      Since you're looking for Dockers that work on specific hardware (armhf), there are going to be several that simply won't work for you. The best choices tend to be among the most popular images, with the most pulls.

      Lastly, your hardware is not blazingly fast and it doesn't have a lot of memory for heavy multitasking. There are limits.
      __________________________________

      In the bottom line:
      If OMV3 and its' Docker plugin, worked correctly with your Dockers; upgraded to OMV 4 (currently a beta) might not have been a good idea. If you had what you want working in OMV3, hopefully your OS is backed up so you can drop back.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 1 time, last by flmaxey: edit ().

    • 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
      ---------------------------------------------------------------------------------------------------------------------------------------
    • Don't get me wrong when I say arm devices are underpowered. (They are, of course.) I'm an R-PI user and I've found that if it's used as nothing but a static file server for 1 or 2 users, an R-PI is enough. It's slow, much slower than what you're using, but for shuffling files around on occasion, in a strict NAS only role, it gets the job done. (At at less than 12 watts.) It was when I attempted to expand to include other services that it's limitations became apparent.
      On the other hand, you're right about OMV; I see an arm devices' ability to run OMV with decent performance as a testament to how efficient OMV is. They run remarkably well with OMV.

      Since you mentioned permissions above, perhaps you're running into issues with accessing data from inside a Docker container or (in the case of a torrent client) getting data collected out of a container. If that's the case, take a look at this -> post.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • 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...
    • In some cases, if you can isolate the file that stores configuration settings and use Volumes and Bind points to map the inside folder containing the config file to the outside, your settings may become persistent and survive container restarts. (On the other hand, I've seen a case where the mapping process killed the container and I have no idea why it would.)

      When it comes to permissions, "root" is at the root of the problem (pardon the pun). A Docker, in most practical senses, is a Virtual Machine. So, the root account inside the docker is not the same as the root account outside the docker. While they have the same name, they are two different users. This is why volumes and mount points are important to pass data (if needed) between the host and docker, bypassing the permissions issue and the barriers set up to prevent the host and container from interacting.

      If you think there's a permission change inside a Docker container that might help your cause, look over this Docker tutorial. In due course, it will explain how to get inside a container on the command line. (If you can get it to run without crashing.) From there you could create users, modify file and folder permissions, etc. In any case, the tutorial is worth doing if for nothing else than to gain insight into how Dockers work.
      __________________________________

      Dockers are great and just like any Linux host, if you can get them to work they're fine and they last. They're so stripped down to the bare essentials, crashing is nearly non-existent. The trick is getting them to work.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 1 time, last by flmaxey: edit ().

    • 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 ().

    • Since architecture is a concern - a note regarding getting the right image:

      When pulling an image from the Docker Hub, most Docker Dev's assume you want (1) the latest image and (2) the most popular architecture which tend to be Debian varieties (not Armbian and similar). Accordingly, if you leave the tag field blank, that's what you'll tend to get (usually Debian or other mainstream Linux distro's).

      To look for the correct tag, if you click on the ! , it will take you to the image Docker Hub Page. In this particular case (image name diginc/pi-hole), look for a link that connects to a "full list of tags". Again, in this case, the full list of tags is 55 - meaning 55 different images, current, old, different architectures, development, etc., could be pulled based on what is entered in the Tag field. In the list, there are 11 arm images, current and past.
      (Also, at the top of some Docker Hub pages, there may be Tab labeled "Tags". Past Docker image builds may be available from this potential source, by entering the tag name or number.)



      For the image named: diginc/pi-hole-multiarch (multi-architecture) there are six additional tags available -> here. An armhf build is among them.


      (You might already know this but it's worth noting for those who may be searching the forum for a solution to Docker issues.)

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 2 times, last by flmaxey: edit ().

    • 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 ().

    • It's good you got what you needed. All's well that ends well. :thumbsup:

      Trash_Can_Man wrote:

      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..
      I wouldn't count on an "auto-detect" feature. I'm not saying it didn't work that way, in this particular case, but there are 100,000+ Dockers out there and such things are only as good as the Dev (with varying levels of expertise, experience and time to invest).

      Usually when one downloads a Docker image name with no Tages, as previously noted, you get "the latest". And while the latest image may work in the majority of cases (that's usually the goal) it's worth noting that it might not work for you. If you think about it, just as it is with Linux desktop distro's, depending on the app's/utilities used, some work better than others on specific hardware. As you're finding, there is no "one size fits all".

      It boils down to finding something that works, maybe tweaking it, and at times that can be a matter of shear persistence.
      (Which you seem to have as a fellow arm user. :) )

      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

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • 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...