Thanks for reply!
If you are ABSOLUTELY SURE that you want to delete them (and all that is inside them), you can do it with sudo OR logged as root.
I asked you for the PATH (the full PATH) of the folders.
That way, I could give you the command.
You only showed the permissions of the folders
I can see the files, I can read/write most of them but got 2 folders that I'm unable to delete now.
Is there way to force delete them?
Show the path for the folders.
Post the output inside CODE box of:
ls -al <PATH to the folders>
OP said Pi5 on the topic.
The bypass was found.
Just use it, 
Can the "winner" be put into a release that does this automatically? Otherwise there will need to be some sort of documented process that people with USB NICs will have to follow.
If this was a general case, I would agree.
But this was only mentioned by you both and with a Pi 5 which not many people are using.
This is a "winner" for the current situation.
If you can deal with it, there's no harm in having that job running. OMV won't delete it in any update.
IMHO, using a USB NIC (even if 2.5G) on a Pi is a waiste of a USB port.
The internal 1G NIC will always be able to be saturated. Don't know if the 2.5G will
long story short i targeted the whole port 4 ( in my case usb4) and it worked , now in the GUI scheduler i have the command below .. and i managed to reboot multiple times with no problem ( decreased the sleep time to 10 seconds )
OK it seems, we have a winner, 
Is there some sort of tool or plugin that enabled one to pick and choose which items to revert?
I was thinking more if you had a OS backup before that date.
Force install prior versions might not be the best way to test it.
linux (1:6.6.20-1+rpt1) bookworm; urgency=medium * Raspberry Pi OS release * Remove unecessary patches * Add rpi featureset * Import Raspberry Pi defconfigs * Allow initramfs generation to be skipped in postinst * Move initramfs-tools to recommends * Install overlays README * Don't sign arm64 kernels * Compress arm64 kernel * Disable unecessary architectures * Use GCC 12 * Add +rpt to abiname * Add epoch support in version string * Linux commit: 6f16847710cc0502450788b9f12f0a14d3429668 -- Serge Schneider <serge@raspberrypi.com> Thu, 07 Mar 2024 14:51:31 +0000
raspi-firmware (1:1.20240306+ds-1+rpt1) bookworm; urgency=medium * New upstream version 1.20240306+ds -- Serge Schneider <serge@raspberrypi.com> Wed, 06 Mar 2024 16:42:23 +0000
These 2 might have messed with something.
If you can revert to PRIOR those updates, maybe it's possible to check a diff somewhere/somewhow, specially the first one:
* Remove unecessary patches *This is me being analytical...
What did you have in mind? I've never had to add anything for gigabit usb network adapters in the past.
Just some thought that cross the mind.
Perhaps something else is needed for lite versions to see the USB NIC since it's Realtek and there's no good stories with that brand on Linux. (AFAIK)
It's strange that the Desktop OS has no issues with it.
And since there's a bit of control on what modules can be passed to function via config.txt, might be one that will work.
Again, haven't read it proper for Pi 5.
Also just remembered
Does the dongle require high power?
There's a line to be changed to feed more power to the USB ports. Don't recall from where I read it.
It's either with vcgencmd or on the config.txt
Maybe just a matter of adding/changing some dt_overlay on config.txt?!?
Raspberry Pi Documentation - The config.txt file
Note: haven't read it properly and have no Pi running.
I can try to use my USB-c 2.5 dongle if I find a USB-a to USB-c adapter once I rotate home.
Just saw this mentioned on the omv-mkaptidx:
# The following error might happen from time to time.
#
# Traceback (most recent call last):
# File "/usr/sbin/omv-mkaptidx", line 27, in <module>
# import openmediavault
# EOFError: EOF read where not expected
#
# To analyse the error execute:
# python3 -vc 'import openmediavault'
#
# To fix this error simply execute the following command:
# rm -f /usr/lib/python3/dist-packages/__pycache__/openmediavault.cpython-32.pycYou can try what it says there:
Check the error with:
python3 -vc 'import apt'
Then check what's on the folder:
[tt]ls -al /usr/lib/python3/dist-packages/__pycache__/[/tt]
Post the output
I did not make a OS drive backup :-/
Then do it now before trying anything else.
Your system is a mess and anything you can try might make it worst or even make it unusable.
In last case, you will have to start with a fresh install.
The amount of upgradable packages don't show it but what is (don't know if it will work)
apt list --upgradable | grep openm
You can test/run any commands from apt with the --dry-run flag to see what it will change on the system:
apt install --reinstall -f --dry-run
Post it's output.
I'll leave the rest inside the SPOILER for later.
Thanks alot, everything is as it should be.
Good to hear.
Care to post again the output of the same command I asked prior?
This time, I trust you have SSH so post it inside a CODE box please (symbol </> of the Blue Ribbon of the posting box)
dpkg -l | grep openm
"Failed to preset unit, unit sshd.service does not exist
This is taking more time than it deserves.
Start fresh following the instructions on the wiki and you will have your system running in no time:
omv7:raspberry_pi_install [omv-extras.org]
Use the arm64 Lite version and don't skip steps.
"iF openmediavault 7.0.5-1 all
That output shows that openmediavault is installed but Half-configured (configuration failed for some reason)
You can try to run the install script again to see if it fixes the install.
In the end, that same output need to show this:
ii openmediavault 7.0.5-1 allAnd the flashmemory plugin will also be installed and running
ii openmediavault-flashmemory 7.0 allFor how to install OMV per the included booklet, what I stated earlier is actually RECOMMENDED in the booklet.
Yes, I understand what you are saying but I'm almost certain that Argon never ASKED if they could do it.
They are selling a product with a install method that isn't endorsed or supported by the developers of OMV.
At least "Officially"
That's all.
because over time I learned that it creates problems for me with some users... let's say... a little sensitive
That's why i'm not a Moderator, 
etc/shadow
At least this one I'm certain that it doesn't have root:root ownership
As for permissions, who knows...
For the OS itself, I am running the suggested Raspberry Pi OS 64bit lite as per suggestions. for OMV I am using the what was said to run in the manual that came with the case.
I really would like ryecoaaron or votdev reply to this with a simple anwser:
Did Argon ever sponsored either of you with any EON to test and "officially support" the hardware???
There has been several people posting threads with issues with EON and OMV and now, you come and say that the Manual on the box instructs to install OMV?
Weird at least...
If you want to continue, post the output of this command:
dpkg -l | grep openmed
I found that ownership of nearly everything on my boot drive had been updated to the wrong user and group. I fixed most of my issues by resetting the ownership of most folders recursively on my boot drive to root:root.
ex: chown -R root:root /etc/
Please, don't advertise this anywhere and to noone.
This is BS.
Your system is FUBAR and you need to do a fresh install to fix that.
The Argon Eon powers on and loads into the OS just fine, the case as a whole seems to be working the way it should be post install of the argon eon software.
Which OS are you using?
Or better yet, did you followed the PROPER instructions on how to install OMV?
omv7:raspberry_pi_install [omv-extras.org]
From the rest of your comments, it seems that you are running a cooked up version from Argon or some other place that uses nginx as default and nothing else.
Because it sure looks you didn't install OMV
