Beiträge von manuel5cc

I recently bought an ORICO 5 bay enclosure and came across this post because I noticed that the disks were spinning down, even when I have this setting deactivated for all of them.

All my disks are used in a mergerfs pool.

For now, I have noticed that, indeed, some disks spin down after some inactivity, so it seems that he unit has some kind of hardware energy management system.

In my case it doesn't affect the normal use, since whenever I need a file that is on a disk, it takes a few seconds but then I can access normally. No problems detected on units unmounting, etc. but will report in a few days.

Regarding this, I read a long time ago (2021) that, if you did reset the dashboard and configured it again, the order in which you tick the modules boxes would be honored (in reverse). Does this still apply?

Zitat von KM0201

one of the advantages of UUID's, is they are static. This is why votdev switched to mounting via UUID years ago rather than by label, etc.

That's very good to know!

Are there any scenarios in which the UUID might change? Just to be aware

Right now my Mergerfs pool consists of 3 external HDD connected to my OMV by a USB Hub.

I'm planning to buy a USB Docking station which advertises that it will show the disks independently in the system. Does this mean that the disks ID will be kept and therefore I don't have to rebuild my pool?

There were some updates yesterday between which one was for the ethernet card. After this update I'm able to set a static IP and commit the changes, so apparently my error was a mix between this issue and the driver.

Zitat von votdev

Yes

Well it didn't. I configured a static DHCP, still got disconnected and had to force reset.

Zitat von votdev

That does not mean you are not affected. The symtoms you describe are matching the problem described in the link. You may apply the changes via UI and then check the status of the service unit. You may also run journalctl -f while applying the changes in the UI. You will surely see that there is some error when getting the IP address via DHCP. To make it short, the OMV project can not do anything here.

So I'm guessing that if instead of using DHCP I configure a static IP the configuration should apply without problems?

Zitat von votdev

Maybe you are affected by a systemd bug. See https://www.openmediavault.org/?p=3492

I have checked this but the service is running apparently...

root@openmediavault2:~# systemctl status systemd-networkd.service
● systemd-networkd.service - Network Service
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-07-17 10:16:46 CEST; 3h 49min ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
   Main PID: 507 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 17801)
     Memory: 4.4M
        CPU: 479ms
     CGroup: /system.slice/systemd-networkd.service
             └─507 /lib/systemd/systemd-networkd

jul 17 11:28:26 openmediavault2 systemd-networkd[507]: vethb063b8a: Link UP
jul 17 11:28:27 openmediavault2 systemd-networkd[507]: vethb063b8a: Gained carrier
jul 17 11:28:28 openmediavault2 systemd-networkd[507]: vethb063b8a: Gained IPv6LL
jul 17 12:58:04 openmediavault2 systemd-networkd[507]: veth6132ac5: Link UP
jul 17 12:58:05 openmediavault2 systemd-networkd[507]: veth6132ac5: Gained carrier
jul 17 12:58:06 openmediavault2 systemd-networkd[507]: veth6132ac5: Gained IPv6LL
jul 17 12:58:07 openmediavault2 systemd-networkd[507]: veth6132ac5: Lost carrier
jul 17 12:58:07 openmediavault2 systemd-networkd[507]: veth6132ac5: Link DOWN
jul 17 12:58:07 openmediavault2 systemd-networkd[507]: rtnl: received neighbor for link '42' we don't know about, ignoring.
jul 17 12:58:07 openmediavault2 systemd-networkd[507]: rtnl: received neighbor for link '42' we don't know about, ignoring.

Zitat von votdev

To me it looks ok. DNS 9.9.9.9 has been set and DHCP has delivered the IP address 192.168.137.246.

What is not working right now? Does name resolution does not work?

Sorry if I didn't explain myself correctly before.

It is working correctly, the problem comes when I try to modify this DNS or deactivate WOL, either via GUI or omv-firstaid. I loose connection and the changes don't apply, I only regain connection (the IP shows again in my network) if I force a reset by disconnecting power.

In my initial setup I activated WOL and put 9.9.9.9 in my dns.

I now want to modify that, basically deactivate WOL and change the DNS server, but everytime I try to do it through the GUI or omv-firstaid, I loose the connection and the changes won't apply.

I have to force the reset of the computer and then the changes revert back and I can connect.

This computer has also a wifi card that I've tried to configure as a fallback for this, but trying to configure it also fails.

Any clues?

Zitat von harryArg

ok, it's the backup 5.2.3 or the borgbackup 5.1.7?

The first one

Zitat von harryArg

Thanks i found rsync in the services section, but i cant finde the backup opcion, do i need to install anything?

You need to activate it first from the "plugins" menu. Then it will show under "System".

OMV has its own backup option (System/backup) for the system disks. I recommend choosing the "fsarchiver" method since it offers the best compression and the easiest restore process. For more info on that restore process you can read this: https://www.fsarchiver.org/quickstart/

For any other sources you can use the Rsync plugin under Services (not sure if you have to activate it first from "plugins").

My approach is usually the first one, but I'm always willing to take the risk if it means better performance and I have a way to go back. Has anyone here tested OMV running with the latest stable firmware?

I usually keep my Raspberry updated with the last software, but don't pay much attention to the firmware and bootloader. For example, my installed bootloader is from a year ago and there is already a newer version.

Is it recommended to always have the last one?

Is omv tested with the default or latest versions?

Zitat von gderf

This applies to any policy that uses "existing path".

Then it's back to a possible policy failure.

Zitat von chente

I think I remember that with some of the policies it is necessary to create the folder where you are writing to the next disk so that it continues to save files. Maybe this will fix it.

Yep I had read about that and recreated the folder structure in all the disks but it didn't work either.

Zitat von chente

Maybe this will help.

Yes, changing the policy works, I am trying the "first found" one and definitely writes the data on another disk, but it's not the behaviour I'm looking for. I still want the disks to be filled starting with the most used. I assume that there is an error with how the "Least Free Space" policy works (at least on my install since others like gderf seem to have no problem).

Zitat von gderf

That's the policy I use here and I have no problems with it.

yep "fsname" is just the name of the filesystem, shouldn't affect anything. I have checked the permissions and everything looks fine, I'll try another policy like "least used space" and see if it applies.

fstab entry looks like this:

/srv/dev-disk-by-uuid-e29462df-9d77-495a-9fdc-805a64c67c73:/srv/dev-disk-by-uuid-c9e7f9f5-1c38-40a5-9793-9806425d13cd:/srv/dev-disk-by-uuid-0382f6c2-c86f-42c8-a3d2-b1277422a9a6              /srv/8043bfca-80c1-4870-a849-9176f9c8bfd6        fuse.mergerfs   defaults,allow_other,cache.files=off,use_ino,category.create=lfs,minfreespace=20G,fsname=megadisco:8043bfca-80c1-4870-a849-9176f9c8bfd6,x-systemd.requires=/srv/dev-disk-by-uuid-e29462df-9d77-495a-9fdc-805a64c67c73,x-systemd.requires=/srv/dev-disk-by-uuid-c9e7f9f5-1c38-40a5-9793-9806425d13cd,x-systemd.requires=/srv/dev-disk-by-uuid-0382f6c2-c86f-42c8-a3d2-b1277422a9a6     0 0

I can't see anything wrong but Im, not an expert really.