Posts by auanasgheps

    Thanks for the help.

    If you are worried about the user admin, well simply don't publish the OMV web UI the internet and use a strong password. After 5 tries the user will be locked, and you'll be able to unlock it via SSH with the utility omv-firstaid

    lol I can't stop laughing

    That's the exact reason why you're having this problem! Before doing radical things to OMV you'd better ask the community. It's better to be safe than sorry

    Not sure if this will help or not, but this is what I did. Before even setting up SnapRAID I had installed hd-idle many months ago per your instructions (Thanks!!) and it was working fine. It was working fine with SnapRAID set up too. Now, once I began running the SnapRAID script, the drives were not spinning down. First thing I did was double-check the script config file and I had it set up to not spin down, so I obviously changed it. That did not change the outcome. It showed in the log file as spinning the disks down, but they never did. All along, hd-idle had been running in the system. Next, I checked the script file and realized that the spindown method 1 was the one that was set active by default. I commented it out and set the method 3 for hd-idle as the active one. It started working after that without issues. Have tested it about 8 times already, with multiple reboots. In summary: Method 1 (SnapRAID spindown) + hd-idle (previously set up and configured) = not working; Method 3 (hd-idle spindown) + hd-idle (previously set up and configured) = working!

    Thanks for letting me know! That's a great news! :) I have updated the script. Can you please try the latest version? I've made also some formatting improvements. Just replace the script file and use your current config file.

    You can use hd-idle on its own.

    The script could also use hd-idle to immediately spin down drives after operations, but this part doesn't work: spins down but immediately after the drives are enabled. I still haven't managed to sort this issue :(

    Does the sync need to be run manually once before the script takes over?

    The script expects to find parity files on parity disks. Therefore, if you're starting with fresh disks, do a manual sync, can be done via the Snapraid section in OMV GUI.

    Since I always worked with my existing array I never thought about this. I will add this to the documentation, thanks for reporting.

    Is it normal to not receive an email if the script fails?

    This script relies on the system SMTP, so is your SMTP configured in OMV?

    Also, is the email in the config script supposed to include the "" (e.g., "") or entered without them?

    Keep the ""

    Do you know if there is a guide out there somewhere about what to do with SnapRAID from the OMV5 GUI in case of a disk failure?

    I'm not sure but I would recommend reading the SnapRAID manual.
    Mostly it's a matter of running the "fix" command.

    I found a simple way to backup: i'm trying the plugin usbbackup in the omv repo. Plugged in my new USB3.0 Disk formatted in NTFS without the need to mount or set anything it; only set source and destination. I hope he'll do the job.

    The "rsync" method you mentioned seems really good, but i'd like to have a second internal drive to use with.

    The plugin is great for a simple copy. I use it every week.
    But it's a simple mirror, not an advanced backup system.

    auanasgheps Thanks for this script! I have been looking for a way to automate SnapRAID in OMV5.

    I downloaded your script on my PC (Win10) and would like to customize and deploy it to my OMV5 installation. Could you provide more detailed steps on how to achieve that? I know that I can very likely customize it using Notepad++, but I have absolutely zero clue how to deploy it to OMV and schedule it. As you can tell, my experience with Linux is limited, but I can make things work with some guidance. Any help is appreciated. Thanks!


    Extract the ZIP and use WinSCP to copy the two files from Windows to /usr/sbin/snapraid. There's no snapraid folder in there so create it first.

    Then follow my simple instructions in Github.

    Making changes it's very easy: every configuration has a description. If you are unsure, don't change it, defaults are pretty good.

    To schedule the script (or really anything else),

    • Login in OMV GUI
    • Go to System > Scheduled Jobs.
    • Create a new job, schedule the execution time. I recommend a daily run when the server is not really in use.
    • Keep user as root
    • Command is the path of the script executable, e.g. /usr/sbin/snapraid/

    Now i have two disks, one for docker and some media i don't really care to keep forever. (But it's always a good thing to backupAnd one DATA disk with all my Life... ) It's a 2TB drive and i'd like to backup on a external USB drive i just bought.

    I'll have a look at borgbackup, thanks

    p.s. nice build, i love the node 304, i have my main pc built on it!

    If you can afford it, use an SSD for docker or general apps data. Databases, cache and thumbnails are much much faster on SSD.
    As a plus, SSD generally don't break, but this is not an excuse to not backup them :)

    Thanks for your effort ryecoaaron

    I can see you're "almost done" with the SnapRAID plugin. Could be a great opportunity to integrate the updated script I make, you may recall our conversation on Github. Let me know if you're willing to do so. Please note this script has additional features over the current one so new UI elements are required, but they're just simple strings.

    Yes, there's a USB backup plugin which I use for my own data.

    If you want to backup a disk that has docker or system data, you'll probably need a more complex solution.

    I use Borgbackup and borgmatic (which helps configuring borgbackup):

    - borgmatic allows to run commands before backups. I use it to pause all my docker containers before the backup. Especially for databases, you'll want things stopped/paused otherwise your backup may not work

    - borgbackup backs docker data up to my other drives

    - once done my containers are restored.

    Borgbackup supports: versioning, deduplication, history, encryption. It's super fast and efficient.

    I can share more details if you're interested.

    Thanks, i swapped sata and power cable with no luck; i placed the disk on a sata usb box and it is definitively dead... It makes strange noises and gives all kinds of errors.

    Now the problem is OMV continue to see it mounted and i don't know how to remove it: maybe is "referenced" somewhere.
    I tried to comment the entry in fstab but it doesn't works.

    Did you enable shared folders or SMB on the drive? Once you delete everything, you will be able to remove the partition in OMV. Just need to find it is used!

    I may be late to the party but just wanted to tell my story.

    I had a similar issue a year ago: somebody logged in my Transmission (torrent) instance and deleted everything*, tried to download a torrent (likely a malware), but ultimately abandoned the task.

    It was my fault: I had authentication enabled on Nginx but not in Transmission, and I'm sure I made a mistake in nginx config. So I disabled nginx auth and enabled it in Transmission using a strong generated password.

    What saved me? Transmission runs in a Docker container, which can only read the torrent download folder. So I just lost a couple of silly downloads and the malware/torrent they tried to download could not go anywhere.

    Also Transmission logs where stored somewhere else so it was easy to find out what happened.

    everything* = only my downloads (hehehe)