500 - Internal Server Error Failed to connect to socket: No such file or directory

Zitat von villeneuve

The conclusion can only be an official fix anyway otherwise it would make no sense to offer mergerfs in the GUI in the first place when it's buggy like that.

This only seems to happen to people who upgraded from OMV5 and with the unionfs in use.

Which I believe is your case.

I'm not well versed on this but the constants are those and when the upgrade changes from UnionFS to MergerFS, something goes sideways.

What I've seen is also the check of "fstab" on the GUI gives issues.

After stopping the Pool and remove it, when recreating it without the fstab checked, it works.

Nonetheless, I'll poke Zoki and ryecoaaron since they're the ones sorting solutions to this issue.

Hm no, in my case it's a totally fresh install of OMV to a clean USB-stick. Only the data drives were previously in use in a mergerfs pool but that shouldn't matter.

To me the error I had and Zoki too which made me think it's a mergerfs issue is this one:

Apr  9 00:09:08 OMV systemd[1]: local-fs.target: Cannot add dependency job, ignoring: Unit srv-mergerfs-jbod.mount failed to load properly: File name too long.

Well, like I said, this is way out of my league.

But there's a github issue already ongoing (although the OP has encrypted drives) regarding this:

fstab option results in boot error and read-only mount · Issue #1 · OpenMediaVault-Plugin-Developers/openmediavault-mergerfs (github.com)

Zitat von ryecoaaron

None of this is the fault of mergerfs. The error you posted is systemd's fault. Not sure how you got a filename too long. I guess that could be the fault of the import but the only solution for that is to delete the import pool from the 5.x to 6.x pool and recreate.

I didn't do any import, I'm experiencing this issue on a totally fresh OMV 6.x install.

Zitat von ryecoaaron

I use this plugin myself on multiple systems. Just because some systems mount slow and have a problem which systemd is trying to protect doesn't mean the plugin is buggy. Is there possible an option that allows a longer delay to wait for these systems? probably but I don't know what it is. All I can say is don't use it if it is "buggy" or help fix.

I just gave a detailed comment in the corresponing issue on GitHub which Soma thankfully had linked to.

When something is buggy I might as well call it that when it's what I experience, it's not meant in an offensive way whatsoever. As mentioned on GitHub I'd help to investigate but need clear instructions how I could do so.

root@SATA-OMV:~# omv-showkey mergerfs

<mergerfs>

<pools>

<pool>

<uuid>70b4c1f4-3c55-464e-ab8a-53730a486dd5</uuid>

<enable>1</enable>

<fstab>1</fstab>

<name>Backups</name>

<mntentref>3782cdce-7ad5-430f-898e-3b198eaddaf2</mntentref>

<paths>/srv/dev-disk-by-uuid-8c3475a0-96ce-4d6c-812c-a14423b3643b:/srv /dev-disk-by-uuid-a3ff8704-56bb-41d8-8901-a10921fc2e3b:/srv/dev-disk-by-uuid-2d3 64564-8c82-49c5-84f5-010bdf1c358c:/srv/dev-disk-by-uuid-b3e385b0-7d1c-42a8-bfde-4592acc47ad8:/srv/dev-disk-by-uuid-16c8d855-d611-4cee-ab20-11deb3691687:/srv/dev-disk-by-uuid-97a0fdd5-4b9a-476b-b160-f8ef7dda48d1:/srv/dev-disk-by-uuid-d2b5fa8 2-7586-4311-a14f-ada8996829a6:/srv/dev-disk-by-uuid-cecec69f-26bf-4cea-842e-8661 105c75b6:/srv/dev-disk-by-uuid-552c447b-7287-4a74-b73e-71ab64268995:/srv/dev-disk-by-uuid-7e037993-306e-473d-9f09-21eacc67755a</paths>

<createpolicy>eplus</createpolicy>

<minfreespace>10</minfreespace>

<minfreespaceunit>M</minfreespaceunit>

<options>defaults,allow_other,cache.files=off,use_ino,moveonenospc=true</options>

</pool>

</pools>

</mergerfs>

root@SATA-OMV:~#

Regarding GitHub: Ok, going back to this forum then. I expected GitHub to be the primary way to communicate in case of bugs.

I have yet to try how it behaves with fstab unchecked. I'm not sure if I manage to try today though. ***

Btw I found that systemd.mount has several timeout options:

x-systemd.idle-timeout=

x-systemd.device-timeout=

x-systemd.mount-timeout=

TimeoutSec=

For details: https://manpages.debian.org/stretch/systemd/systemd.mount.5.en.html

And on https://forums.debian.net/viewtopic.php?t=138716 I found this statement:

"See systemd-mount(5) for the details but basically you need to make a foo.mount unit file and use the After= and Wants= directives to control the ordering."

***EDIT I just tried the behaviour with fstab unchecked and so far so good: it booted up fine with the mergerfs pool fully working. I'll shut down the machine today and report back if the issue reappears when I boot it up again on sunday or next week.

So this is sorted for now. I think moving to systemd is more robust as fstab, because if your mergers does not mount with fstab the root fs will be read only, which should not happen with systemd.

Zitat von Soma

This only seems to happen to people who upgraded from OMV5 and with the unionfs in use.

Which I believe is your case.

I'm not well versed on this but the constants are those and when the upgrade changes from UnionFS to MergerFS, something goes sideways.

What I've seen is also the check of "fstab" on the GUI gives issues.

After stopping the Pool and remove it, when recreating it without the fstab checked, it works.

Nonetheless, I'll poke Zoki and ryecoaaron since they're the ones sorting solutions to this issue.

Alles anzeigen

I've been fighting the read only fs on boot drive for the past few days. Fresh install of omv6 to new SSD, not an upgrade from omv5.

Finally found a couple threads (including this one) indicating turning off fstab option for mergerfs may fix it. Assume it did for me as well if I don't post back while crying heavily.

Thanks to all for making this forum so valuable!

markmarz Since I did leave the fstab option turned off the problem has not returned on my OMV6 system so I assume that you'll be fine.

Zitat von villeneuve

markmarz Since I did leave the fstab option turned off the problem has not returned on my OMV6 system so I assume that you'll be fine.

Exactly! It's your experience (and others) that is turning my frown upside down.

Ha-hah!

But I may be crying tomorrow.

I've been waylaid by updating my motherboard and as luck would have it, the first one was faulty. And turns out recent motherboards are UEFI only, so have to rebuild boot disk, blah blah blah. So naturally I was focused on more motherboard problems with the replacement (also ASRock, different model). I had just put an order in for an ASUS mb to see if that would help when I found this and other forum entries detailing the problem and (hopefully) solution. I cancelled the ASUS order and will give mergerfs another shot tomorrow.

Thanks!

so this is a solution to a issue that I had with : 500 - internal server error failed to connect to socket no such file or directory

root@raspberrypi:/home/pi# dpkg -l | grep openm

ii openmediavault 6.0.44-1 all openmediavault - The open network attached storage solution

rc openmediavault-flashmemory 6.2 all folder2ram plugin for openmediavault

ii openmediavault-keyring 1.0 all GnuPG archive keys of the OpenMediaVault archive

rc openmediavault-omvextrasorg 6.1.1 all OMV-Extras.org Package Repositories for OpenMediaVault

root@raspberrypi:/home/pi# systemctl status openmediavault-engined.service

● openmediavault-engined.service

Loaded: masked (Reason: Unit openmediavault-engined.service is masked.)

Active: inactive (dead)

I first unsmasked the service

root@raspberrypi:/home/pi# systemctl unmask openmediavault-engined.service

Removed /etc/systemd/system/openmediavault-engined.service.

Ran again to see the status :

root@raspberrypi:/home/pi# systemctl status openmediavault-engined.service

● openmediavault-engined.service - The OpenMediaVault engine daemon that processes the RPC request

Loaded: loaded (/lib/systemd/system/openmediavault-engined.service; enabled; vendor preset: enabled) =======>>>> now is loaded ( no unmask status )

Active: inactive (dead)

Started the service

root@raspberrypi:/home/pi# systemctl start openmediavault-engined.service

root@raspberrypi:/home/pi# systemctl status openmediavault-engined.service

● openmediavault-engined.service - The OpenMediaVault engine daemon that processes the RPC request

Loaded: loaded (/lib/systemd/system/openmediavault-engined.service; enabled; vendor preset: enabled) ==========>>>>

Active: active (running) since Wed 2022-10-19 17:41:35 EEST; 1min 8s ago ==========>>>>

Process: 78728 ExecStart=/usr/sbin/omv-engined (code=exited, status=0/SUCCESS)

Main PID: 78730 (omv-engined)

Tasks: 1 (limit: 8986)

CPU: 197ms

CGroup: /system.slice/openmediavault-engined.service

└─78730 omv-engined

Oct 19 17:41:35 raspberrypi systemd[1]: Starting The OpenMediaVault engine daemon that processes the RPC request...

Oct 19 17:41:35 raspberrypi systemd[1]: openmediavault-engined.service: Supervising process 78730 which is not our child. We'll most likely not notice when it exits.

Oct 19 17:41:35 raspberrypi systemd[1]: Started The OpenMediaVault engine daemon that processes the RPC request.

Now the Web/gui works.

Cheers

This fixed my similar problem

sudo systemctl unmask openmediavault-engined.service

Zitat von gmstalk

This fixed my similar problem

Code

sudo systemctl unmask openmediavault-engined.service

I already was root ( so I did not need to quote "sudo" first )

Cheers