Beiträge von rez

  • Union Filesystems crashes - "Transport endpoint is not connected"

    Just to add to this I had the same problem with a Rock64 and mergerfs (same versions of everything I believe). I was mounting directories as recommended.
    I never got to the bottom if it as I sold my Rock64 and got a Pi 4 with more RAM which I needed, but just thought I'd add that it seems something specific to that build of OMV/the plugin on a Rock64.


    Also @trapexit just to say thanks for an excellent piece of software and all the support you give here and in other forums!

  • Union Filesystems Plugin - Errors: (OMV) 'Transport endpoint is not connected' - (Finder) 'The operation can't be completed because the original item for "x" can't be found.'

    Zitat von Mumbedeus

    Hello!


    Did you ever solve this? I have the same problem with my Rock64 4GB now...


    Best regards
    Marius

    I'm not the OP, but I had the same error using a Rock64 1GB. I never managed to resolve it and ended up selling it and getting a Raspberry Pi 4 which works fine now with OMV 5. I know this probably doesn't help much, but you're not alone in having issues with the Rock64. I suspect there is something about the hardware/

  • Unionfilesystem Plugin

    Ah okay, same version as I've tried. I did try mixing different drives (just selecting 2 rather than 3, and trying different combinations), but had the same error. I also tried the command line version rather than the plugin, but had dependency issues there (and I couldn't install the dependencies because they had circular dependencies!).


    Also no on the missing file system question.

  • Unionfilesystem Plugin

    Zitat von BobbyS

    Edit: So I have seemed to fix it. Truthfully, I don't know how. I kept uninstalling the plugin and reinstalling it. Either that fixed it, or I create a UNFS with different drives, created the shared folder, then changed the drives in the UNFS, and then restarted the OMV install.


    Regardless, one of those fixed it for users having the same issue.

    Is it actually all working fine for you now? Speed reasonable, etc? What build are you using?


    I'm having an issue as well, using the Ayufan build of OMV for Rock64 (but also getting issues with the Armbian build) when trying to share a merged drive:
    https://forum.openmediavault.o…o-share-the-pooled-drive/

  • MergerFS (Unionfs) error when trying to share the pooled drive

    Hi all,


    I'm using ayufan build of OMV 4 for Rock64. Everything is working fine, except trying to set up unionfs plugin from the GUI.


    I install the plugin, update everything, and then add drives to a pool.


    In my scenario I'm adding 3 drives (connected over USB3) and calling it 'drivepool1'.


    It successfully creates the pool, however when I go to make it a shared folder I get this error:



    I have to say that I can't understand any of it!


    I did try using the armbian build from sourceforge and I didn't get this error, but I was having other issues using unionfs on that build (incredibly slow access to the pooled drives), and in general the ayufan builds have been better for me in the last few months of usage.


    Anyone with any ideas..?


    Thanks!

  • "fatal error: runtime: out of memory runtime stack" when trying to access the docker plugin in OMV. Rock64

    Thanks! That makes sense if I don't have any swap configured... I'll try that image when I get a chance. Hopefully I can backup and restore my settings...? I'll give it a go using the guides on here anyway.


    Serves me right for not being more careful with what image I use! I thuought I got it over on the ayufan github, but now I can't seem to find it so guess I'm wrong.


    Thanks again for the help guys.

  • "fatal error: runtime: out of memory runtime stack" when trying to access the docker plugin in OMV. Rock64

    Thanks both for your replies. I suspect I may just be being naive about linux memory usage behaviours, but hoping someone on here might have some ideas about why it's causing errors rather than just becoming slow (using more disk swap space).

    Zitat von tkaiser

    Since you're running on ARM can you please provide output from sudo armbianmonitor -u after such an occurrence?

    That command didn't work (says armbianmonitor: command not found), but I tried 'top' to view memory stats. It does indeed look like including the buffer/cache usage it's only leaving <15MB 'free' (screenshot of that info along with the processes listed as using resources). I also tried the meminfo command which shows the second screenshot.


    However, I gather than Linux will try and use up as much memory as possible to speed up apps. My understanding though is that it should then relinquish some of that memory when you need to start up something else, or do something new...
    Currently showing ~120MB 'available', which I would assume should be available for this sort of purpose?


    Given the above, it may explain why I can't start new docker containers (less so why I can't start a container I know takes <10MB total), however I don't understand why it would throw that error just trying to go into the docker plugin in OMV (or e.g. stopping a running container in Portainer, giving a similar error).

  • "fatal error: runtime: out of memory runtime stack" when trying to access the docker plugin in OMV. Rock64

    Hi all,


    Currently using OMV4 on a Rock64 1GB board. So to start, yes I know I only have 1GB of RAM, however OMV is showing memory usage of <60%.


    I'm usually running a few docker containers (emby, sonarr, jackett, duckdns, portainer, transmission), and they will all start off fine, however after a few hours I will no longer be able to go into the docker plugin without it throwing an error. Also if I try and start/stop any of them in Portainer (or view container stats) I'll get a similar error (even trying to stop one!).


    The running containers all still work perfectly fine when using them, however trying to manage any of them or start/stop new ones that gives me errors.


    If I look at them after a couple of hours (before I have issues) none of them seem to be using excessive amounts of RAM... Including cache, emby is ~100MB, sonarr ~100MB, jackett ~100MB, portainer <20MB, transmission ~50MB, duckdns <5MB. In total that's less than 400MB.


    I'm not sure what the memory footprint of OMV itself is, or the couple of plugins I have enabled (OpenVPN, docker, SMB sharing, shellinabox), but looking at the System Information tab of OMV shows <60% memory usage.


    Am I missing something, or should I expect this? Is OMV not reporting 'real' memory usage? If there's some 'invisible' memory reservations, shouldn't it be grabbing some of this when it needs it? What about swap space? (Shouldn't it use that rather than just failing..?).


    Forgive my beginner ignorance about everything, I'm not a linux expert and have only been using OMV for a few months now!


    I've attached a screenshot of the System Information page of OMV, and below is the full error that appears when trying to access the Docker plugin page in OMV.


    Code
    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; docker images 2>&1' with exit code '2': fatal error: runtime: out of memory runtime stack: runtime.throw(0xac644d08, 0x16) /usr/local/go/src/runtime/panic.go:616 +0x64 fp=0xffb99d08 sp=0xffb99cfc pc=0xab520860 runtime.sysMap(0xb2200000, 0xbe00000, 0xab501401, 0xad66de60) /usr/local/go/src/runtime/mem_linux.go:227 +0x124 fp=0xffb99d34 sp=0xffb99d08 pc=0xab507284 runtime.(*mheap).mapBits(0xad6602d8, 0xbe000000) /usr/local/go/src/runtime/mbitmap.go:160 +0x98 fp=0xffb99d4c sp=0xffb99d34 pc=0xab503bf8 runtime.(*mheap).setArenaUsed(0xad6602d8, 0xbe000000, 0xade00000) /usr/local/go/src/runtime/mheap.go:545 +0x24 fp=0xffb99d58 sp=0xffb99d4c pc=0xab51644c runtime.(*mheap).init(0xad6602d8, 0xade00000, 0x200000) /usr/local/go/src/runtime/mheap.go:530 +0x44c fp=0xffb99d6c sp=0xffb99d58 pc=0xab516054 runtime.mallocinit() /usr/local/go/src/runtime/malloc.go:392 +0x218 fp=0xffb99db0 sp=0xffb99d6c pc=0xab5016d8 runtime.schedinit() /usr/local/go/src/runtime/proc.go:490 +0x68 fp=0xffb99de0 sp=0xffb99db0 pc=0xab5233d4 runtime.rt0_go(0xffb99f74, 0x2, 0xab54bf18, 0xf727d000, 0xaaaaaaab, 0xa1d64080, 0xa97bbadd, 0x130, 0x0, 0xac623251, ...) /usr/local/go/src/runtime/asm_arm.s:159 +0x84 fp=0xffb99e20 sp=0xffb99de0 pc=0xab54bfac