Beiträge von heiner

    Thanks for keeping this plugin alive :)


    Sorry if this was already answered, but I got no hits searching.
    For various reasons I share the root of my drives and want to change the location of the snapraid.* files to a subfolder.
    Is there any supported way of making manual changes to the snapraid.conf or do I have to edit the script at /usr/share/openmediavault/mkconf/snapraid to make persistent changes?

    I would have already raised the issue on the bugtracker, but I cannot reproduce it.
    Is anyone else who has encountered this able to safely reproduce it?


    From the actual script I cannot even fathom any case - except for maybe the server losing power while the script is still running - where the cleanup trap would not be sprung.
    Yet the lockfile was again present on my 24/7 server this evening, with all the above listed consequences.
    Puzzling..

    I have run into the same phenomenon.
    There are various threads regarding this issue on the board. As recent as from last month.
    This one seems to be the most thorough one, though.
    Thanks for starting the debugging on this, 71CHi2OOeuF2.


    To summarize: when automatic samba recycle bin emptying is enabled, OMV creates /var/lib/openmediavault/cron.d/samba-recycle-$uuid:


    Which crond calls daily via /etc/cron.daily/openmediavault-samba-recycle:

    Bash
    #!/bin/sh
    # This configuration file is auto-generated.
    # WARNING: Do not edit this file, your changes will be lost.
    set -e
    run-parts --regex='samba-recycle-*' /var/lib/openmediavault/cron.d &>/dev/null

    The samba-recycle script does various sanity checks, one of which is if the script is already running (by testing for a previously created lockfile):

    Code
    # Exit if another job is running.
    [ -e /var/run/samba-recycle-$uuid ] && exit 0


    From my observations every time I run into the " samba recycle bin emptying not working"-issue, the lockfile exists (preventing any future manual or automatic execution of the recycle script), even though the script is not currently running.
    Manually deleting the lockfile temporarily alleviates the issue.


    Further debugging the scripts I was not able to manually reproduce the conditions that lead to the lockfile /var/run/samba-recycle-$uuid being left over after script termination.
    Any shell magician that could chime in with an insight into what could cause these seemingly sporadic/random issues?



    Edit: as to the ampersand you mentioned, 71CHi2OOeuF2: I don't know why changing I/O redirection (without the &, stderr is no longer redirected to /dev/null) would make any difference on your end.
    At least it does not seem to change or fix the issue for me.