Posts by crashtest

Quote from moisemust

Sorry the page is in French (which is my native language).

I saw the page in English. (Most browsers have plugin's that can translate.)

Quote from moisemust

Would something like this be good?

Check the measurements to see if it will fit inside your case. Generally speaking, drives goes in one side of the cage and the cabling goes in the other side, so that means you'll need some space on both of the open ends of the cage. That means you'll have to watch were you mount it.

Notice that on the side with the grill; the grill screws in on the top and (maybe) the bottom, meaning the grill is not a door. You might not be able to use the grill.

Quote from macom

They have always been considered as optional to reduce writes a bit more. And editing fstab to add these options caused quite some corrupted fstabs. I assume for these reasons they have been removed from the instruction (or not added to the wiki).

The gains from the additional "teaks" were minimal and, in some instances, only applicable to very specific use cases. When weighed against user mistakes being made in configuration, it was decided that the small differences wasn't worth the potential for damage.

Quote from moisemust

I don't think installing to a USB flash drive would be a good idea.

I've never used anything else (other than a flash drive) to boot OMV. With the flashmemory plugin installed, they last a long time. While I've had a few SD-cards fail (most of them were cheap generics), I've only had one good quality USB thumbdrive fail. It was at least 5 years old. It might have been 6 or 7. It was old enough to where I'm not sure of the exact age. I'll qualify that and say that I use my server as a NAS. (I'm not running Dockers or a media server from my flash boot drive.)

The real benefit with a flashdrive is, they're easy to clone. If a thumbdrive fails, replace it with a cloned backup and the server is up again in a matter of minutes.

Quote from NsinghP

(What I'm thinking is using 128Gb NVMe as container installation drive and 128Gb Sata SSD as data drive for all the docker apps) <--I don't know if that makes sense.

As long as they're off the MergerFS mount point (Dockers, VM's, relational DB's) you should be OK.

Quote from NsinghP

I have decided to use a 32Gb USB Pen drive, instead of 128Gb Nvme, M.2 SSD for my boot device

I think that was a good move. Thumbdrives are easy clone and, if there's an issue, restoration is easy and there's no need to crack the case. Lots of people assume they're getting better server performance when booting from SSD's, Nvme's, etc. That's not really true. After the boot cycle is over, most of the key OS components (the Kernel, etc.) are running from RAM.

There are some exceptions like running VM's or a lot of Dockers from the boot drive. If you're doing that, since you're using MergerFS for data drives, a good use of the Nvme would be for Docker containers (especially media servers), VM's, relational DB's, etc.

_________________________________________________________________

This is a walk through for using -> rsync to mirror a disk. It might give you a couple of ideas to work with. If the destination drive is large enough (in your case 5 or 6TB), a MergerFS mount point can be the source drive. Restoring to the backup drive is straight forward.

Quote from rafroma

1- why should I use Midnight Commander? Can I move data from w10 workstation using OMV samba share, acting directly on the network folder I can map in my w10 workstation?

2- if I well understand once formatted as EXT4 the HD can be used with w10 only via SMB, is it correct?

1. A local "drive to drive" copy is faster than copying over the network. Using Midnight Commander or a command line copy, might apply if you have enough room on the existing EXT4 drive, to house the data that's currently on the EXFAT drive. Copying the data to a W10 wrk station and moving it back again is fine, but that's over the network which is slower.
2. Yes. This is what OMV was designed to do. (NAS - "Network Attached" Storage.) SMB can store DOS file properties and with the addition of usernames and passwords, as noted in the NAS permissions doc, OMV will allow transparent user access that includes write access.

On the other hand, there are a few options to get Windows to be able to -> "read" EXT4 if you really want to attach the drive to W10. ("Write access" is another matter.)

Before digging any farther into this, are you booting from an SD-card? If so, what brand of SD-card are you using, how old is it and do you have a back? Odd behavior is a hallmark of a marginal SD-card.
________________________________________________

Quote from go_niko

So I just moved it all onto a single drive, but a drive that's still part of the mergerfs pool. So that should still be safe, right?

That should be OK. Again if you're using Most Free Space, over time given normal additions and deletes, data should balance around what Docker is using on the single drive.

However, -> this is what I find concerning. This is why I wanted to look at the output of dmesg. On the other hand, if there's a kernel freeze / panic, I'm not sure what happens to the dmesg log.
________________________________________________


Reboot again, wait for a LUKS lock event and run the following:

journalctl -k >kernel.txt

That will dump a text file into the root user's folder. Move it to one of your shares and post it on-line.

Move the data to a windows workstation, format the drive connected to OMV to EXT4, then move the data back to the reformatted drive (over the network) using an SMB share. (You might be able to copy the data from one drive to another, at the OMV server, using Midnight Commander.)

Before objecting to this idea, think about what happened:

If you formatted a drive on OMV, with a Linux native filesystem like EXT4, then simply moved it to a Windows Server or Workstation, would you expect permissions to work seamlessly? Even if the drive is recognized (using something like -> this ) you might get read access but "write access" might be problematic. The same holds for a Windows "foreign volume" that's simply connected to a Linux server.

The only way to get "clean permissions" for Windows data, stored on a Linux server, is by using an SMB share. SMB is designed to be a Windows to Linux translator of sorts. Even in those circumstances, permission rules should be observed. -> NAS permissions.

Quote from rafroma

but nobody is able to write on the HD in EXFAT, only on the HD in EXT4.

This is because permissions, on a Linux server (using a Posix compliant file systems like EXT4, XFS, etc.) are not the same as permissions on an EXFAT or NTFS hard drive. EXFAT and Posix permissions don't map one to one.

The EXFAT drive was not, BTW, formatted on OMV.

Try the following.

For hidden files:

--exclude=".*"

Folders:

--exclude=".*/"

Both:

--exclude=".[!.]*"

_____________________________________________________________

Quote from toralex

but after executing the cron job in the log files I see that the quotes are gone

/usr/bin/rsync -a --exclude .recycle/ \

Out of curiosity, does this change cause a problem with the transfer?

The log is a few minutes long. Did the drives lock during this period?

Are you storing Dockers and images on a MergerFS array? Dockers shouldn't be housed in the MergerFS mount point. Dockers use a version of overlayfs that is not entirely compatible with MergerFS. Further, Dockers are constantly manipulating container files (not unlike the activity that's normal for a boot drive).

The issue can be worked around by installing Dockers on a single drive's mount point. If you're using Most Free Space, your drives will balance out over time but, after installing to a single Drive's mount point, note that you can't use the "Balance Tool" (in the MergerFS plugin).

Quote from dwilly2

so I ended up taking a different approach & managed to get OMV installed.

Just as a note; I've built OMV onto a thumbdrive at a workstation. When the build was finished, I moved the thumbdrive to a server.

Quote from dwilly2

I had screwed something up trying to change to a static IP so I couldn't test the web GUI.

Generally speaking, it's best to go with the DHCP default until you get into the GUI, then change to static addressing

Quote from theJester1975

All 6 drives are connected in the hot swap bays. Why would this not work?

Because those 6 drives are, most likely, connected to a HBA (Host bus adapter - usually a RAID card). Typically, BIOS looks for bootable drives at SATA/SAS ports that are on the motherboard, not an add-on card.

A workable option is to build OMV on an 8GB thumbdrive. Try it.
BTW: Cezi_86 is right about the flashmemory plugin. You'll need to install OMV Extras and the flashmemory plugin, to use a thumbdrive as a boot drive. Once OMV is up an running, here's a -> guide for doing that.

Reboot the R-PI. Wait for the lock again. (Maybe encourage it with disk I/O, if that's what causes the lock.)
Then, in an SSH session, do dmesg --time-format=iso.
dmesg is the kernel log. Scroll through the output and look for errors.

Quote from go_niko

Nope not using a UPS - think it might be dips in power causing me to lose the drives?

It's possible. There are a great many power line effects that we, as customers, don't see. The question is, what is the tolerance of the device? I've see this first hand. I had a commercial server and a workstation on line, at the same time, sitting side by side. I saw a very short but noticeable power hit where the workstation reset and started rebooting. The server was completely unaffected. I believe the difference was due to a much higher quality power supply in the server.

There are power transients that are fast enough that we don't see them with the naked eye, but they may affect our devices. (Especially those tiny little switcher power cubes that have the bare minimum of components.) If your drive enclosure PS is more sensitive than your RPI PS, the RPI may be seeing a disconnect from the drives. Admittedly, this is a guess.

If you can, I believe your best path would be a large drive that would let you get out of LUKS. Maybe a self powered external drive that's independent of the enclosure. (Which is a single point of failure.) You need backup in any case. You're taking a risk without it.

Maybe do the touch every 10 minutes? If you're OK with drives spinning (I am) try 5 minutes.

Just curious, are you using an UPS?

Quote from NsinghP

Had hard time setting up email notification. Had to Setup two factor authentication on my gmail account first. Then had to generate an App Password and enter it in OMV before emails started to work. Attaching screenshot for reference.

Sometimes, when providers require secured ports, it can be tricky. I'm in a situation that requires IMAP so I set up my servers to send E-mail to a pop3 account which forwards to my IMAP account.

Quote from NsinghP

Next I am going to look into backing up the Boot/OS disk and then Data Disk.

-> This might help.

Do you have a cable to attach an external monitor?

Noting that you have 6 hard drives installed:
If you're trying to boot from a drive connected to an HBA (not the motherboard), in most cases, it won't work.

You might try installing OMV to a USB thumbdrive (at least 8GB), and setting your BIOS boot order to USB first.

Set up -> Notifications. 

Under Storage, SMART, Settings, Enable SMART (at the top).
Under Devices, Enable monitoring of each drive

Under Scheduled Tasks, you can Create, Enable and Schedule a Short Test for each drive.

My preference is a short test, in the early morning hours, each Sunday.