Euer Verein Baut Scheisse und man wird Stehen Gelassen ? Ich glaub es halkt oder was denkt mal Ja nicht ihr Steht hier über allem sonst Sorge ich dafür das die Verbugte Software Verschwindet. Datenverlust ohne Ende durch eure Inkompetenten Programmierer mal sehen was ein Fachkundiger Anwalt dazu sagt dann ist hier Schluß.
Very well. I expected nothing less from someone like you.
I'm closing this thread because I already know where it ends. Good luck with your lawyers, too.
Die Updates sind NICHT OK sonst Könnte ich mich ja Anmelden.
Er fährt jetzt nicht mehr Hoch, ganz Toll.
I love it when a new user comes to the forum asking for help with such a friendly attitude.
Good luck with your system and your problem. Maybe someone would be willing to help. 
Mojnsen.
Enen die neuen Updates Installiert und die haben dann mal eben mein Homeserver Zerstört, Herzlichen Dank für Updates die Fehlerhaft sind und damit alle meine Daten VErloren.
First of all, welcome to the forum.
The updates are not defective.
Your data has not been lost.
If you provide more details, we may be able to help you.
CodeASM1062 Serial ATA Controller
That's what I wanted to know. That chip shouldn't cause any problems in RAID configurations, so everything seems to be in order. I can't think of any other ideas at the moment.
With 16GB, you have more than enough RAM to use ZFS without any problems.
I haven't used Ubuntu in a while, but the steps are the same as in Windows.
- Create a share in OMV.
- Create a user in OMV.
- Grant permissions on the share to that user.
- Enable the Samba service.
- Add the share in Samba to share it.
- Mount it in Ubuntu using the username and password that have access permissions (not root).
Maybe this will be useful for you. https://wiki.omv-extras.org/doku.php?id=omv7:new_user_guide
I'd check your Proxmox configuration. I think this is a Proxmox issue, not an OMV issue.
oh my god! Im so sorry. i got confused and posted a different OMV problem. I been trying to fix too many things at once
Okay, don't worry.
but its show up in disk fine
Does that mean the hard drive appears in the Storage|Disks tab? Remember, I'm not in front of your system. Please try to be more specific in your statements.
If I understood correctly, the initial objective of your first post was to mount an NTFS-formatted hard drive in OMV. Did you achieve this?
I don't understand how what you say in your second post relates to what you're trying to do in the first.
You're wrong about that. The need for large amounts of RAM to use ZFS is an urban myth. Read the OpenZFS documentation and you'll see that a system with 2GB of RAM can run ZFS without problems if you don't use deduplication. In this case, I agree with crashtest; I would recommend using ZFS for many reasons.
Read here
And regarding ECC memory, that's another myth. It's not necessary, even though it's recommended. It's also recommended on any other file system; the difference is that OpenZFS clearly states this, while the documentation for other systems isn't so clear. But if you don't use ECC, you'll most likely never have problems, just like on any other system.
In any case, you're using it for professional purposes, so it wouldn't hurt to consider using ECC RAM.
Im running proxmox version 8.4
Make sure you have configured the VM correctly and that OMV can see that hard drive.
Consider that on one of the servers I had an auth problem in sending emails: inside /etc/postfix/sasl_passwd there was the wrong password while on the GUI the password was correct, so the check worked but the emails did not send (and there were a thousand).
I did a test and saw that when you change the password on the GUI, the password in /etc/postfix/sasl_passwd is also updated so I don't know why they were different. Maybe I changed it by hand years ago for some insane reason.So most likely the failures occurred at different times.
That really invalidates the time coincidence. If you mentioned it before in this thread, I missed it, sorry.
Unfortunately for me no, it's not a joke.
Yes, I already ruled out that possibility. It crossed my mind only because it wouldn't be the first time in this forum. But I'm sure it's not the case this time, unfortunately for you.
They are virtually identical, except for the disk sets.
Can you give a brief description of the hardware? Motherboard, CPU, etc.
As specified, the NAS are not located in accessible areas.
The head of the company is the only one (with me) that can access the server rooms. If he enjoys kicking the NAS and then paying to fix them... I don't know, it would be stupid.
Perhaps inadvertent sabotage? I'm guessing someone entered those rooms to sweep and mop the floors. You say they're located on the floor. Perhaps someone moved them while they were running to sweep them, which could cause these hard drive errors.
ZFS would be a great alternative and we used it on the main rack mounted NAS.
If I remember correctly, the problem was the RAM needed (too much for small systems).
They asked me to make the configuration of the various NAS as similar as possible so I switched everything to ext4.
You're wrong about that. The need for large amounts of RAM to use ZFS is an urban myth. Read the OpenZFS documentation and you'll see that a system with 2GB of RAM can run ZFS without problems if you don't use deduplication. In this case, I agree with crashtest; I would recommend using ZFS for many reasons.
_________________________________________________________
Regarding letting hard drives spin up and spin down, if you search on Google you'll find opinions for and against. It's not proven, but stopping and restarting the hard drive can often cause them to fail more quickly. I've had them running 24/7 since I got a server; I've never considered stopping them, and they've lasted for many, many years. But I've always used dedicated NAS drives.
What if I as owner/admin, want to access OMV remotely (outside my LAN) for what ever reason, maybe to retrieve an important file that I need, do maintenance, etc
To access your entire network remotely (including the OMV GUI), I would use a VPN. The Wireguard add-on is ideal for that purpose. https://wiki.omv-extras.org/do…v7:omv7_plugins:wireguard
Could be OMV7
I'd look elsewhere for the cause, for the same reason as in point 2 of my argument. I'd be surprised if this happened to just one person. OMV is used in countless systems. We'd have the forum flooded with complaints.
This thread is puzzling.
The fact that simultaneous failures (or failures within a short period of time) occur on multiple hard drives could suggest a faulty batch, but I find andrzejls's theory about the hardware surrounding the hard drives more plausible.
However, it's very rare for the same thing to happen on two different servers at the same time, with different hard drive models in both servers. This invalidates any theory related to batches of hard drives with manufacturing defects. It also invalidates the theory that some server component, such as the power supply, could have caused this, since it has happened on two servers with two power supplies and different hardware.
So, analyzing everything that's been said, this seems more like a mystery movie than anything else. I can think of a few theories:
1. That you're pulling our leg. If you were a relatively new forum user, that would be a possibility, but considering you've been a forum member since 2018, it's unlikely, so I'm ruling it out.
2. You're using similar hardware on both servers, and there's been a recent update that harmfully affects that hardware. For example, the same SATA port expansion card. It could be, but I'd be surprised if it only happens to you. So I'd rule out this option.
3. Sabotage. You say these servers are in a company. Has it occurred to you that a disgruntled employee might be kicking the servers when no one is looking? That would explain it. I think I'll stick with that option; I can't think of anything else.
I want a user (one denoted in the access control list or what ever method OMV uses to specify people that can access OMV)) to be able to transfer files from their machine to my OMV or have them download files from OMV to their machine.
For that specific purpose, I would install Nextcloud on Docker. That's what I do on my server.
Did you look at the wiki?
Note for 'chente': I have a monitor and a keyboard connected to the host, but since I am not an expert in Linux, I prefer not to cause damage by tinkering with the code.
I only responded to your request for help running a command line.
If you request help in this forum, you'll often receive instructions asking you to run commands in the CLI. Often, these will be simple commands requesting information about your system and its status. Other times, they will be commands that actually execute some change to your configuration to resolve a problem.
You should familiarize yourself a bit with the command line, for example, so you can Google the suggested command and know what you're doing before doing it.
Oh yeah, go into /etc/openmediavault and copy config.xml. You could then clean-reinstall your system on a new drive (keep the old one for further data-extraction/reconstruction) and copy your config.xml back and see if that restores your system to it's old state. Use the old OMV-version, before the upgrade. So basically after booting your new-old installation, copy that config over the one you have and issue a redeploy command. In my head that seems fusible. What do the experts in here think? Could that be a practical solution to rebuild a lost system?
That's the basic operation of omv-regen. But it's a bit more complicated than replacing the database.
What do you see in the Storage > File Systems tab? Are there any missing file systems?
Ciao, sto provando a inserire il codice ma non ci riesco perché sono bloccato nella schermata di login. Cosa posso fare?
Try this (Use a translator):
If that's really the problem, you could try solving it with a command in Scheduled Tasks that restarts the SFTP service some time after the server starts. 60 seconds might be enough.
