Posts by auanasgheps

    Development was completed a couple of weeks ago, since then I've tested the plugin on my real OMV NAS.

    No issues to report, will open a PR now on GitHub.


    Please let me know how to contribute to the Wiki, I have a draft for that as well.

    A quick update.


    I've finished adding functionalities: I believe the plugin is feature complete.

    I'll be testing the plugin on real hardware for a while, then I'll prepare the PR on the GitHub repo.


    I've also prepared a draft documentation for the Wiki.


    A couple of highlights:


    - Added a "Last Run" column to show last execution result, which is parsed from /var/log/snapraid.log



    - Added Apprise test button for notifications and emails.


    Why does it bug you? What are you trying to solve? The plugin is using snapraid 12.4 from the Debian repo. https://packages.debian.org/trixie/snapraid

    It's just cosmetic, but my script uses it: snapraid -v does not print the snapraid binary version, just prints "none".


    I discovered that this issue is actually fixed in Debian Repo for forky which has the 13.0 Snapraid binary.

    13.0 is just a bugfix version, we could backport that. Are backports available already?


    (14.x is moving quite fast and I would not go on that)

    Alright. The script already handles dependencies via apt, so we're covered.

    I implemented deletion of /etc/snapraid-aio-*.conf files on package purge.


    One side question: how the snapraid binary is compiled for the main plugin? There's a little issue that bugs me that I want to solve, but the "snapraid" repo is archived.

    Full steam ahead, I also added some commands.



    A couple of questions for you ryecoaaron


    - Apprise handling Apprise is needed for service notifications, but not strictly required for a bare-bone run. I know users do use it. Its binary is not in `debian/control` Depends/Recommends; enabling Apprise without it fails mid-run with a cryptic error. Should it be added to Recommends? I believe it's needed.
    - postrm cleanup Should we delete /etc/snapraid-aio-*.conf files left on disk after plugin removal?

    I wrote a separate plugin for snapraid-aio-script but auanasgheps hasn't had time to work on it more. Once this plugin is complete, it would replace the current diff script included with the plugin (which is old, not really maintained, and not written by me).

    As I shared on the other thread: working on it right now :) hopefully we can share more updates soon!

    Hello, long time no see!

    In the meantime I have gained some decent experience with Claude Code, and started working on the plugin.


    I use AI for lots of things but it hallucinates with OMV coding quite often.

    Heck yes: in the beginning I was spending more time fixing bugs introduced by Claude, rather than being productive.
    I found my way out of this madness, by creating a ton of "Project Memory" based on the OMV documentation for developers (grateful for its existence).

    I've extended the plug-in a lot, below there's a sneak peak.

    I think I'm satisfied with the current UX and functionality. Now I have to validate the configs produced by the plug-in, for this I will need some time.


    It's in my github repo, forked from ryecoaaron's. When ready, I'll do a PR.


    We also need to decide what is the future of this plugin: will it be standalone, but relies on main SnapRAID functionality for arrays, or we integrate it in the main one, deprecating/removing the old script?





    Per-config scheduling

    • Each configuration now has its own Schedule button directly on the config list. No more global enable toggle — schedule each array independently with a dedicated cron entry.
    • The schedule form defaults to a custom midnight run so you can adjust the time immediately without switching modes.
    • The "Scheduled" column in the config list shows at a glance which configs have an active schedule. If a schedule was manually deleted from the system, the plugin detects this and reflects it.

    Improved notifications

    • Native OMV email is now a toggleable option per config. Sender and receiver are pulled automatically from OMV's notification settings — no manual entry needed.
    • Apprise notifications are fully wired up, including support for attaching the full report on warnings. Works independently from native email.
    • Apprise Email (SMTP via Apprise URL) is available as a separate option for setups that want email without configuring OMV's native mail.

    Cleaner UI

    • All form fields now have clear labels and descriptions. Ambiguous labels (Apprise, SMART log, SnapRAID status, verbosity, spindown, etc.) have been rewritten.
    • The ignore_pattern field is flagged as advanced with a misuse warning.
    • A link to the official AIO Script project page is shown at the top of the config form for quick reference.
    • Remote Docker management has been removed from the UI (advanced feature, unlikely for a OMV user). Docker container management for local containers remains fully functional

    Quality of life

    • Saving or cancelling a config or schedule now redirects back to the config list automatically.
    • The SnapRAID array selector shows the array name (from /etc/snapraid/ symlinks) instead of the raw config file path.

    Bundled script

    • Ships with snapraid-aio-script v3.4 stable.

    Uhm, a first issue arises during the command line installation for dependencies.

    It warns are missing, but are not installed.


    To install, I had to run apt --fix-broken install

    Don't know why.

    Feedbacks:

    Notification Settings

    This section of the script actually uses postfix configuration from OMV, so the user doesn't have to configure anything manually.

    Since the user has already configured Notification options, I would inherit those values. (simplicity)


    Check for script Updates

    Please disable the option and remove it: the user will not be in control of updates since we'll manage them via package updates


    Healthchecks

    Healtchecks UUID and Healtchecks URLs should be grayed out if "Use Healthchecks.io" is disabled, which is by default. If enabled, they are mandatory fields.


    Apprise

    The same applies with Apprise: the URL field should be grayed out if the main option is disabled, mandatory if enabled.


    I think some options clashed between Apprise and Apprise Notifications.


    Can you make two distinct sections?


    Apprise Notifications

    Use Apprise Notifications

    Apprise Attach report

    Apprise URL



    Apprise Email notification

    Use Apprise Notifications

    Apprise Attach report

    Apprise URL


    NOTE: this is an advanced setting, not super relevant to OMV the average user. The main benefit for OMV users is the attachment feature not available in postfix.


    Telegram and Discord

    These are legacy integrations before I developed the Apprise integration. Please hide them. The Discord integration is very unreliable. Apprise is much superior, I don't want new users to go for these old features.





    Log SMART Info


    SMART_LOG_NOTIFY requires SMART_LOG to be enabled first.


    Run 'snapraid status'

    SNAP_STATUS_NOTIFY requires SNAP_STATUS to be enabled first.


    SnapRAID configuration file

    This should be instead a dropdown menu with a list of the available configuration files.


    Please note that the script can be used for multiple configuration files, creating a separate AIO config for each SnapRAID script.

    Honestly I don't know how many users do multiple SnapRAID configurations, but since it's a feature, we should probably follow the same approach and make the AIO configurations for each SnapRAID configuration.


    Docker and service management

    Since we removed remote Docker management, now "Manage local Docker Containers" is redundant since the user would have already selected "Manage Docker containers / services".


    Can you hide the entry but still enable it if the user enabled "Manage local Docker Containers"?


    Lables and titles

    I will take care of this.

    I wanted to test it right now but my testing VM has OMV7 and the plugin requires OMV8. Is there a dirty way to upgrade to OMV8/Debian 13?
    I would not do this in real world, it just to get it up and running quickly.

    Yes, I think it would make sense to only pull running containers. Those are the ones that need to be stopped/paused.


    I also think we can discard the "Remote Docker Management" section, since it's for very advanced uses where SnapRAID and Docker are not running on the same host.

    I was really hoping to hand this off. I can help but I don't use snapraid or the script. So, it is really hard for me to test. I also don't really know how the script should be used. Creating this initial plugin was about all of my available time for a while which was much less work than getting the current plugin to stop using the old script and start using the new one.

    I really appreciate it.
    I've delayed my help for an official integration because I wanted to make changes to the script, but I hadn't had time until recently.


    The logic is always the same: automate all SnapRAID routine actions. Some of these things are very specific to the SnapRAID world. However, the description I've added to each field in the configuration file should be enough to explain every option, at least for a SnapRAID user.


    In addition to the core SnapRAID actions, the script does some nice things.


    An example is the Docker management. When SnapRAID is running, no application should write any data to the array.

    To resolve this problem, my script stops or pauses containers during the execution.


    Currently, a user has to enter the containers manually. Could we pull containers names so they can be selected with a dropdown list?

    Hi ryecoaaron, thanks for the initial effort on this!

    Please note that I've been working a lot on the dev branch.

    Most of the changes are done, I just need to merge a PR.


    I had a quick look and it seems that you used the master as a reference.


    Therefore, regarding the configuration reference and descriptions which needs to be exposed in the UI, please refer to this: https://github.com/auanasgheps…ob/dev/script-config.conf


    What's the "logic" of the plugin? I would expect it to expose most/all configuration options and push them to the config files. If it's only this, the testing shouldn't be too much hard.


    A nice to have would be to install automatically the dependencies. The script handles this automatically, but I think would be best to integrate them in the install phase.

    Required:

    - curl

    - jq

    - bc

    - python3-markdown


    Optional: Pipx + Apprise for enhanced notifications.