Beiträge von crashtest

First off, you might think about getting another SD-card that is identical to the card you have. Put the current card up somewhere and use the new card for a new build. After you get something that works, the second card can be used as a clone for OS backup using this -> process.

Zitat von Fatality2024

If it turns out that the preinstall Script wasn't used and I'm forced to a reinstall, what would be the best way to perform it?

Do a standard R-PI install as outlined in the -> R-PI document which includes the preinstall script That does mean the loss of all current configuration but that's the fix. (Again, this time around, clone the SD-card once it's configured and working. With a clone, you'll have a quick recovery option in the future.)

Zitat von Fatality2024

To keep my settings, I should most likely start with the OMV-regen command to backup my settings in advance, omitting the Network interface settings, as proposed by chente. Where will this backup be stored?

I don't know what to tell you here. I've always done clean installs, then reconfigured from scratch. (While that can be labor intensive - I believe scratch rebuilds help to keep admin's familiar with the configuration processes required by the GUI.)

In the bottom line, I haven't used OMV-regen. If you want to use it, the best thing to do would be read over the -> OMV-regen document and look through the questions thread at the end. Additional questions from there would be best directed to chente.

One difficulty that I can foresee is that the R-PI must be on the network to download the script. At this point, that's probably not possible. (Keep in mind that I'm speculating on what "might" have happened, based on what you described in your first post. We won't know for sure until the wired int name is confirmed.)
Assuming that networking is out, I suppose the OMV-regen script could be downloaded to another host and placed at the root of the R-PI's SD-card, using a file-manager. Then it could be executed on the R-PI using the cable for a CLI console connection as root (or, in the case of the R-PI, as sudo).

Zitat von Fatality2024

Yes, as far as I rember, I did follow the mentioned guide.

It's important to "know" that the preinstall script was used. Otherwise, without the script, networking dies after a change to networking is made.

The issue has to do with Debian's use of "Predictive Network Interface Names". The problem comes to the surface with R-PI's, when changing anything related to networking in the GUI. The preinstall script fixes the issue by turning off predictive naming for the first fixed interface and sets the interface name to eth0.

In the existing build that's not responding to the network:
Using the HDMI cable will let you see the CLI but I don't believe you'll be able to fix the networking issue. If you do, I'd be interested in what you did. (BTW: when on the CLI, if the wired interface is named end0, the preinstall script wasn't used.)

In the bottom line, rather than try to fix networking, it would easier to reinstall OMV using the recommend process.

Your call.

Did you install according to -> this process?

After the R-PI image is burned to an SD-card:
There are two scripts involved, in the OMV install process. The first of the two scripts, a "preinstall" script takes care of the issue that I believe you're experiencing. If you didn't run the preinstall script and made a change to networking in the GUI (saved it, etc.), it's simply easier to reinstall.

Try the process above.

Since it appears that you have OMV installed, perhaps looking at this -> Doc, starting with -> Creating a Network Share, might be helpful.

Zitat von fahlide

In the future, I plan to create a raid mirror for NAS, how should I install it?

A RAID mirror (in my opinion) is a waste of a hard drive. You might consider using Rsync to mirror drives. That would provide 100% backup that's restoreable if the primary drive fails. How to set up Rsync for drive mirroring and how to restore to the backup is covered -> here.

Did you follow this -> Install Process?

You can do what you're suggesting with Rsync. As chente has said, getting the source and destination right and whether the copy is local, or local to (or from) a remote, are the keys to getting the command line right. If the copy is local to local, it's pretty simple. If a remote server or client is involved, it becomes more complex.

Keep your Dockers on the NVME. I'm assuming that your 64GB thumbdrive is for the OS.

SnapRAID + MergerFS is a good choice for data drives, especially if your 3 spinning drives are connected by USB. SnapRAID will provide drive recovery abilities along with file / folder restoration abilities and MergerFS provides drive aggregation. While other file formats will work, for SnapRAID and MergerFS, EXT4 is the best choice 90% of time.

These doc's are for OMV6 -> (SnapRAID and MergerFS) but their information applies to OMV7 and their screen shots are close enough for setting up both packages in OMV7. READ them and consider following their external links for more information about the packages, from their supporting websites.

This has the solution you're looking for -> NAS Permissions. Specifically, set up the user's home folder as a -> Personal / Private Share.

After powering the NAS down, yes.

-> Cloning Flash Media.

Backup guidance:

General guidance

Clone Flash Media (OS Backup)

Simple Data Drive Backup

The above are effective and easy to do and, more importantly, easy to restore if there's a problem. However, there are many ways to backup the OS and data that are more sophisticated. With some time and familiarity with OMV and server operations, it might be worth looking into the backup topic in more detail.

Keeping in mind that I don't use encrypted disks and I have never used the LUKS plugin in Openmediavault:

Following is what I did:

1. Under System, Plugins, I Installed the LUKS plugin - openmediavault-luksencryption.
2. I added a new disk.
3. Under System, Storage, Disks, Wipe, I did a quick erase. (Note that OMV will not allow you to erase an existing disk if it has a mounted filesystem. Further, an existing filesystem won't unmount if it's referenced with a Shared Folder or another configured item.)
4. Under Storage, Encryption, in the Device Field, I selected the new disk and supplied a Passphrase.

5. Under System Storage, Filesystems, I selected the + button (Create and Mount a Filesystem), I chose EXT4 and selected the newly encrypted drive in the Device field.

For a test, on the encrypted drive with the EXT4 filesystem, I set up a:
- Shared Folder (Test2 in this case) Permissions used "Everyone"

- A Test2 SMB share layered onto the Test2 Shared Folder above. Permissions "Guests Allowed" with "Read only" unchecked. (This step assumes that SMB is set up and activated.)
- Finally, from a LAN client, I found the Test2 share and copied files into the SMB share.

I tested the above with a reboot to insure all was well, that the drive unlocked and that the files were available.
________________________________________________________________________

The above is the process I used.

Have you read this ? -> NAS Permissions.

If you don't know how to use the Linux CLI to examine permissions using PuTTY; when looking at shared folder permissions -> WinSCP might be helpful.

SebastianS1986 You might want to look this over -> NAS Permissions.

Zitat von SebastianS1986

Can nobody give me an answer here?

Are you trying to delete, from a client, the network share itself? (Consisting of a "shared folder" and an "SMB" share layered on the shared folder, that you created on the server.) You can't do that and, I'd have to ask, why would you want to? The network share is a server container for files and folders.

With admin rights, you can delete the contents of the share, but the share itself is deleted at the server by:

1. Deleting the SMB share.

(followed by)
2. Deleting the shared folder.

Having dealt with disk encryption in the past (corporate level), unless you really need it, I wouldn't do it. In some cases, if there's a filesystem issue, encryption makes working on a drive problematic. Often, the only solution is reformat and start over.

Encryption makes sense for business laptops where there's the possibility of theft. The same would apply to corporate servers where securing valuable proprietary information is a priority or where disgruntled employees might be in the picture.

At home, the greatest likelihood of data theft is "over the wire", after drives are unlocked. In that scenario, drive encryption is useless.

For general reference -> NAS permissions.

Zitat von hornetts

Aside from reinstalling again with all defaults, I'm not sure what fixed it.

Corruption can happen for an assortment of reasons. If you have a complex configuration, dockers, etc., you might consider backing up the OS.

Zitat von Fizzi

OMV on an M2 SSD --> I clone it to a USB drive or another SSD

and then I would be safe?

Test the clone. It would be worth the time to know that it works. If it does, you're safe.

Those groups (and the admin user) are system groups for making administrative changes in OMV, through the GUI, without the need for root user access. For NAS operations and normal user access, there's no need to edit these groups or to add non-system users to them. To avoid breaking OMV, they should be left alone. If you're experimenting with these groups, on a active server, backing up the OS is highly recommended.

The command you'd want to use is:

less /etc/group

The named OMV specfic groups are:

openmediavault-config:x:995:openmediavault-webgui

openmediavault-engined:x:994:openmediavault-webgui

openmediavault-admin:x:993:admin

openmediavault-webgui:x:992:

openmediavault-notify:x:991:

The function is explained in the name.