Posts by tsch

I want to use the mergerFS-Pool as Mediaserver containing large files in different directories and I don't want to care about where I have to create new directories. If possible I'd like to use the drive on which a directory first was created and write to exactly this drive until it is full and then automatically mergerFS creates right this directory on another drive in the pool where most space is available.

This should prevent OMV to spin up all drives but only the drive I'm working with a directory.

Am I thinking wrong here or is there a perfect policy for me? Which would this be?

And how would I remove a drive from the mergerfs-pool?

Thanks a lot, did the trick and after reboot the newly added capacity is available.

Thanks ryecoaaron for your fast answer.

So you mean edit the existing pool:

and then select filesystems and only the additional drive?

I installed another drive to my OMV-NAS which is formatted and mounted.

What exactly is the correct way to add this new drive to my existing mergerfs pool?

I managed to delete the old content files from the drives using WinSCP and now the SnapRAID-sync is working.

I've deleted the snapraid drives and afterwards the array.

snapraid status

shows:

Self test...
No configuration file found at '/etc/snapraid.conf'

What seems logical, because I've deleted the snapraid drives and array.

Now I "only" have to get rid of the old and from my point of view useless snapraid data on the drives to establish a new array with drives.

I mounted the 4 data drives and found files from my old SnapRAID.

How can I delete them because this seems to be the problem?
I can see the files when mounting via CIFS on my Windows client but I can't delete them.

Quote from gderf

Obfuscating things like disk UUIDs is pointless and makes it difficult to provide help.

OK, now without obfuscating:

Self test...
Loading state from /srv/dev-disk-by-uuid-5508a4d1-cedd-4806-9e7c-d7eadebd8f38/snapraid.content...
WARNING! Content file '/srv/dev-disk-by-uuid-5508a4d1-cedd-4806-9e7c-d7eadebd8f38/snapraid.content' not found, attempting with another copy...
Loading state from /srv/dev-disk-by-uuid-a9d18d21-b31e-4672-a992-edc2f6c402c2/snapraid.content...
WARNING! Renaming disk 'data1' to 'Data3'
Error decoding '/srv/dev-disk-by-uuid-a9d18d21-b31e-4672-a992-edc2f6c402c2/snapraid.content' at offset 143
The CRC of the file is correct!
Disk 'data2' with uuid 'e8c4828b-325a-452b-9a56-12a18b551192' not present in the configuration file!
If you have removed it from the configuration file, please restore it

END OF LINE

After a completely new installation of OMV7 because of a failed bootdrive I installed the SnapRAID-Plugin and now struggeling with the setup.

I added my 4 data and 1 parity drive in the same SnapRAID-Pool.

Initializing the SnapRAID pool shows the following error:

Self test...
Loading state from /srv/dev-disk-by-uuid-...../snapraid.content...
WARNING! Content file '/srv/dev-disk-by-uuid-...../snapraid.content' not found, attempting with another copy...
Loading state from /srv/dev-disk-by-uuid-...../snapraid.content...
WARNING! Renaming disk 'data1' to 'Data3'
Error decoding '/srv/dev-disk-by-uuid-...../snapraid.content' at offset 143
The CRC of the file is correct!
Disk 'data2' with uuid '.....' not present in the configuration file!
If you have removed it from the configuration file, please restore it

END OF LINE

I'll give the OMV-backup-plugin a try and save the image to another NAS.

I just did a backup with USB Image Tool, restored it to another USB stick and it's working like a charm.

Would have preferred a automatism without need to pull out the stick, but anyway.

Quote from crashtest

tsch
This is an example of where cloning or otherwise backing up your OS drive, using a method you can easily restore, is a very good idea. If by chance you find yourself with a failed boot drive, recovery would be free of computing drama.

Your're absolutely right crashtest.

But unfortunately here we have a classical blind spot in the otherwise exemplary OMV-documentation.

Exactly this is what I'm struggling with: How can I automatically backup my USB-Drive or SSD with the OMV-system to another NAS and how exactly is the restore process? All this for someone with 5 thumbs in every hand regarding LINUX.

Is SanDisk Ultra Fit USB 3.1 a good choice?

Quote from ryecoaaron

I have a few systems booting off usb sticks for years with no issues. This is not a grub issue.

Which USB sticks do you use? This would be my favourite approach for OMV.

Quote from mischka

Boot from a Debian 12 installation USB stick and repair Grub using the Rescue function. This usually works well.

I'm wondering why I have trouble after only a few weeks booting from a SSD connected to the USB Port.

I'd like to avoid running into the same problem again.

Unfortunately my Mainboard doesn't support booting from NVMe plugged in a PCIe adaptor.

Is Grub not stable working on SSDs on USB or is it possible that I have some problem with my hardware?

There seems to be a difference between the old SSD (not booting):

and the newly installed OMV on a similar SSD:

Quote from mischka

Boot from a Debian 12 installation USB stick and repair Grub using the Rescue function. This usually works well.

Thanks mischka, I'll have a try.

Where can I find more noob-proven documentation how to use the rescue function to repair grub?

Could GRUB fail? If so, how can I repair it?

I'll try a new installation which boots and then recover the OMV partition to the new SSD.

Quote from gderf

You will need to provide more details about this. Just saying that it doesn't work isn't enough.

From one day to the other I couldn't wake up the NAS via WLAN and booting ended in opening the BIOS of my Asus H87I-PLUS.

The SSD is correctly discovered by the BIOS but Boot ends in the BIOS with a back screen and showing the cursor in the upper left corner for some seconds before.

If there is other information I can give you, please don't hesitate to ask which information you need and how I can provide it.

I'm no LINUX-Pro but -Noob unfortunately.