Posts by VaryingLegwarmer

    Sounds about right, can also be a problem with the smb libs the devs are using. Not clear. People are having similar problems over at Unraid:
    https://forums.unraid.net/topi…anic-and-internal-errors/

    Samba Error Help
    Quote Feb 9 13:23:17 Tower smbd[22785]: [2023/02/09 13:23:17.454400, 0] ../../source3/smbd/close.c:1485(close_directory) Feb 9 13:23:17 Tower smbd[22785]:…
    forums.unraid.net

    15195 – Permission denied calling SMBC_getatr when file not exists

    15247 – Permission denied when trying to delete file from android clients (gvfs?)

    Whenever swiftbackup on Android syncs backups to an OMV smb share I get a bunch of emails with subject "[omv.local] Panic or segfault in Samba Inbox"


    The email body is the same for all except that the PID changes. Didn't use to happen to me on omv6 with SMB and share settings unchanged. On the forums others had similar issues because they installed omv in a Pi but in my case OMV is installed on a USB drive. The notifications they got were also a little bit different.

    Code
    The Samba 'panic action' script, /usr/share/samba/panic-action,
    was called for PID 1974104 ().
    
    This means there was a problem with the program, such as a segfault.
    However, the executable could not be found for process 1974104.

    Other than this, all backups seem to have been written to the share without issues. But I get dozens of these emails in the process.


    Below are the share settings. I don't think I've changed much from default after creation and haven't touched since:


    On the service settings screen I do have some extra options:


    Extra options:

    Code
    mangled names = no
    dos charset = CP850
    unix charset = UTF-8


    Any ideas on how to address this are appreciated.

    Reboot. Uninstall again. The continue with the steps.

    I just did that now but this happened:



    What should I do now?

    The purge command failed for me see output below. What's the best way forward?

    Is this the advice for everyone who installed the plugin and it's running it without any (apparent) issues?

    After I reboot omv for whatever reason I've yet to mount all my luks drives which I do with a script (I don't want them to automount) but in the meantime OMV sends out emails, dozens of then in a span of just minutes, with subjects like "Monitoring alert -- Status failed mountpoint_srv_dev-disk-by-uuid-08b70414-1010-4cba-88a3-e777d6bd8fb0" I do like to get these emails but not as frequent, is there a way to configure the frequency?

    Btw emails have been working fine since yesterday without having had the time to install the test flashmemory.. only thing I did difference was run `sudo omv-mkaptidx` to fix the update notifications on the dashboard which doesn't seem related but I'm reporting it for visibility anyways. Haven't restarted OMV so might lose it then. Once I have more time I'll play with this again and report back.

    By the way I never got any E-mail out of the OMV despite the Email settings are prperly setup but don't know if something else is blocking the E-mails from the Pi and honestly I won't have time to diagnose that so I rather will go ahead to extract the ps.txt file out of the Pi which has not been as easy as I thought it would be, but as soon as I have time I will do it and share it here

    Emails are off topic but it's been reported in this thread and others: you can follow it here.

    After I configure the mail, test notifications work, but after a while they stop until I restart the server.

    Facing this exact same reason after upgrading to OMV7. In my case I am using gmail for notifications, same settings as I had on omv6. Edit, for the record, I have not installed the 7.1 test version of the flashmemory plugin but I did the omv-upgrade yesterday and still facing the same issue with the mail plugin. Should I go ahead and install the 7.1 version?

    Facing the same issue after upgrading to OMV7. Same plugins, same containers. My guess that OMV (or Debian) just changed the way it's accounting for ram and it's caching more than before but seeing how they say it's not because of OMV or Debian means they have no idea. Getting chatgpt to interpret the top output still suggests OMV baseline consumption increased. Attaching ps output in case someone can see anyting out of the ordinary there. The amount of docker related processess seems to have increased but honestly I never paid much attention to that before (unlike the ram widget in the dashboard which I did pay attention to).