Posts by Sean

    Hi,


    I am using mergerfs with a pool of 4 disks. I am using the policy "existing path, most free space" and the additional options "defaults,allow_other,direct_io,use_ino,ignorepponrename=true".


    Now three of the disks are 86% full, their usage history looks as in attachment "data4". But one disk is only 76% percent full, the usage history is in Attachment "data1". As you can see, even when the usage of the other disk increased heavily during last December, there is no real change for Disk 1.


    At first I expected the "existing path" policy to be the problem, but this is *not* the case: the directory where all the new files go is present on every disk.


    Any idea what could be the reason for this behaviour?

    OK, I haven't done this myself, but I'm using a snapraid + mergerfs config, and one of the reasons I do so is that the files themselves are stored as they would be in a single disk system.


    So if it doesn't work after just installing the old disks with the new system, all you need to do is to rebuild the parity disk (OK, might take an afternoon) and reconfigure the union directories. You should only have to remember the ID of your parity disk so you don't use a data disk as new parity disk. ;-)

    How about linuxserver/transmission?


    https://hub.docker.com/r/linuxserver/transmission/tags


    Thanks in advance!

    OK, I played around with top, but I didn't find anything suspicious (except that the mldonkey process is running as "root", although it's a docker image - is ist supposed to be like that?)


    I also checked the logs, and I found this:



    I remember I had similar errors (reported by the BIOS) some years ago, and they just went away after a while.


    I have another mainboard lying around I could install in my nas. Can I just replace an Intel Celeron board with an AMD Athlon II board, or is that going to break the OS?

    Hi,


    sorry for the general topics - I'd like to be more specific, but the symptoms are not clear.


    After my summer vacation, I switched my nas back on, and didn't notice anything - until the first "snapraid sync" job - see my thread here:


    Lots of snapraid errors


    After a few days, I received warnings about high cpu load again, waited for a longer time, but I had to use the reset button after half an hour.


    The CPU load seems to increase gradually over time - after a reboot, it's 0.1, yesterday and the day before it was above 1, this morning it was down to 0.1 again, so I felt relieved - until I saw the uptime: 10 hours, so it rebooted during the night again :-(


    I didn't change anything about the configuration, can't find any suspicious processes, and would be grateful for hints regarding where to start tracking down the reason for the problems.

    Hi,


    I may have done something stupid. A few days ago, my OMV NAS was unresponsive (no Web UI, no ssh, no Samba), and so I rebooted it after a few minutes (later I found some mails about exceeded resource limits, so that probably was the reason).


    Now I did the first "snapraid sync" since the reboot, and I get lots of errors:


    Code
    Data error in file '/srv/dev-disk-by-label-Data4/file1.mkv' at position '1064', diff bits 73/128
    Data error in file '/srv/dev-disk-by-label-Data3/file2.mkv' at position '232', diff bits 69/128
    Data error in parity 'parity' at position '7632915', diff bits 1/2097152
    Data error in parity 'parity' at position '7634385', diff bits 1/2097152
    Data error in parity 'parity' at position '7635226', diff bits 1/2097152
    Data error in parity 'parity' at position '7635622', diff bits 2/2097152
    Data error in parity 'parity' at position '7638365', diff bits 1/2097152


    and even


    Code
    Verifying /srv/dev-disk-by-label-Data1/snapraid.content...
    Verifying /srv/dev-disk-by-label-Data2/snapraid.content...
    Verifying /srv/dev-disk-by-label-Data3/snapraid.content...
    Verifying /srv/dev-disk-by-label-Data4/snapraid.content...
    DANGER! Wrong file CRC in '/srv/dev-disk-by-label-Data3/snapraid.content.tmp'
    Verified /srv/dev-disk-by-label-Data4/snapraid.content in 10 seconds
    Verified /srv/dev-disk-by-label-Data1/snapraid.content in 10 seconds
    Verified /srv/dev-disk-by-label-Data2/snapraid.content in 17 seconds


    Since the errors are on different disks and the disks are all healthy according to the SMART info, my guess is the problem is with the snapraid data (maybe I intererrupted the "snapraid sync"?).


    fsck also looks good:



    Now my questions are: Am I right in thinking the data is OK, it's just the parity that's fucked up? If so, how do I fix it?

    Hi,


    I've been using docker for a few weeks now, and it's mostly working fine, but some questions have come up.


    - When I configure the upload/dowload speed through the web UI, transmission seems to forget the settings after a while.

    - Some settings like the name of the "incomplete" directory can't be configured through the UI at all.


    I found the "settings.json" file in the "settings" directory, and I changed some of the keys, but after a restart of the container some of them were changed to their former settings.


    Is there a way I can prevent the settings from being changed? Will I have to manually edit this file every time I restart the container or update the image?

    Hi,


    sorry for another noob question, but I haven't found anything in the forums or the documentation.


    I have installed two docker images (besides portainer), linuxserver/transmission and logicwars/mldonkey.


    How does updating work? It seems they have no auto-update functionality.


    In the omvextras-tab in the web-UI, there are the options "update", "omv-update", "upgrade", and "dist-upgrade". What do they do? Do they refer to the docker plugin or the images?

    OK, I guess (hope) I can answer the question myself now. My clamav was running amok because it couldn't access the folders it was supposed to scan, so it spammed the logfiles until the system disk was full (and maybe also caused a high memory / processor load). So it probably didn't have anything to do with Samba.


    Just in case anyone (including myself) runs into the same problem later :-D

    Hi,


    in the last weeks, I had weird problems with my SMB shares: Sometimes they were extremely slow (like 100 Bytes/sec), then the transfer came to a complete halt, and the client couldn't find the shares anymore at all. However, in the dashboard SMB was still displayed as up and running. After a server reboot, the shares were visible again, but unreliable as before. Sometimes they are working fine, with 100MB/s.


    Previously, the server ran smoothly for years. I don't know what I changed, a few weeks ago I installed the recent updates for OMV4, a few days ago I updated to OMV5 because I hoped it would fix this problem, but it didn't. I'm also having this issue with several clients, so I don't think it's client-related.


    Any ideas? I haven't found anything in the forum / common problems thread.

    Sorry, that was my mistake. I thought the "+" was for adding new scanning tasks, but it's actually for adding new shared folders. I didn't expect that in the clamav dialog.

    OK, thanks!


    That took care of the error, but now I can't add new scanning tasks:


    Code
    The configuration object 'conf.system.sharedfolder' is not unique. An object with the property 'name' and value '<Directory>' already exists.
    Error #0:
    OMV\AssertException: The configuration object 'conf.system.sharedfolder' is not unique. An object with the property 'name' and value 'Jan' already exists. in /usr/share/php/openmediavault/config/database.inc:495
    Stack trace:
    #0 /usr/share/openmediavault/engined/rpc/sharemgmt.inc(281): OMV\Config\Database->assertIsUnique(Object(OMV\Config\ConfigObject), 'name')
    #1 [internal function]: Engined\Rpc\ShareMgmt->set(Array, Array)
    #2 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
    #3 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('set', Array, Array)
    #4 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('ShareMgmt', 'set', Array, Array, 1)
    #5 {main}


    Can I remove these entries manually? If so, where is the file located?

    I'd be happy to uninstall / reinstall clamav if that will solve the problem.


    Edit: I noticed that the transmission server is still running. Is this correct? Should I uninstall it manually? Will it cause any trouble if I just leave it installed?

    And when I click on "show details":


    Error #0:
    OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; omv-salt deploy run clamav 2>&1' with exit code '1': orion.local:
    ---------- ID: remove_clamav_clamdscan_cron Function: file.absent Name: /etc/cron.d/openmediavault-clamdscan Result: True Comment: Removed file /etc/cron.d/openmediavault-clamdscan Started: 15:41:50.576316 Duration: 13.5 ms Changes: ---------- removed: /etc/cron.d/openmediavault-clamdscan
    ---------- ID: remove_clamav_clamdscan_cron_scripts Function: module.run Result: True Comment: file.find: ['/var/lib/openmediavault/cron.d/clamdscan-c855889e-0b7d-4995-80b1-d464bdbb132b'] Started: 15:41:50.591626 Duration: 4.754 ms Changes: ---------- file.find: - /var/lib/openmediavault/cron.d/clamdscan-c855889e-0b7d-4995-80b1-d464bdbb132b
    ---------- ID: remove_clamav_daemon_logrotate Function: file.absent Name: /etc/logrotate.d/clamav-daemon Result: True Comment: Removed file /etc/logrotate.d/clamav-daemon Started: 15:41:50.596732 Duration: 2.533 ms Changes: ---------- removed: /etc/logrotate.d/clamav-daemon
    ---------- ID: remove_clamav_freshclam_logrotate Function: file.absent Name: /etc/logrotate.d/clamav-freshclam Result: True Comment: Removed file /etc/logrotate.d/clamav-freshclam Started: 15:41:50.599526 Duration: 2.264 ms Changes: ---------- removed: /etc/logrotate.d/clamav-freshclam
    ---------- ID: configure_clamd_apparmor_profile Function: file.replace Name: /etc/apparmor.d/usr.sbin.clamd Result: True Comment: No changes needed to be made Started: 15:41:50.602060 Duration: 10.997 ms Changes:
    ---------- ID: configure_clamd_apparmor_local_profile Function: file.append Name: /etc/apparmor.d/local/usr.sbin.clamd Result: True Comment: File /etc/apparmor.d/local/usr.sbin.clamd is in correct state Started: 15:41:50.613348 Duration: 14.167 ms Changes:
    ---------- ID: reload_clamd_apparmor_profile Function: cmd.run Name: apparmor_parser -r /etc/apparmor.d/usr.sbin.clamd Result: True Comment: State was not run because none of the onchanges reqs changed Started: 15:41:50.630422 Duration: 0.016 ms Changes:
    ---------- ID: configure_clamav_freshclam Function: file.managed Name: /etc/clamav/freshclam.conf Result: True Comment: File /etc/clamav/freshclam.conf is in the correct state Started: 15:41:50.630599 Duration: 99.593 ms Changes:
    ---------- ID: stop_clamav_freshclam_service_to_force_db_download Function: service.dead Name: clamav-freshclam Result: True Comment: onlyif condition is false Started: 15:41:50.755229 Duration: 3166.416 ms Changes:
    ---------- ID: start_clamav_freshclam_service Function: service.running Name: clamav-freshclam Result: True Comment: The service clamav-freshclam is already running Started: 15:41:53.923199 Duration: 73.728 ms Changes:
    ---------- ID: wait_for_clamav_freshclam_db_download Function: file.exists Name: /var/lib/clamav/main.cvd Result: True Comment: onlyif condition is false Started: 15:41:53.997441 Duration: 32.609 ms Changes:
    ---------- ID: configure_clamav_freshclam_logrotate Function: file.managed Name: /etc/logrotate.d/clamav-freshclam Result: True Comment: File /etc/logrotate.d/clamav-freshclam updated Started: 15:41:54.030549 Duration: 9.486 ms Changes: ---------- diff: New file mode: 0644 user: clamav
    ---------- ID: configure_clamav_daemon Function: file.managed Name: /etc/clamav/clamd.conf Result: True Comment: File /etc/clamav/clamd.conf is in the correct state Started: 15:41:54.040309 Duration: 212.535 ms Changes:
    ---------- ID: start_clamav_daemon_service Function: service.running Name: clamav-daemon Result: False Comment: Service clamav-daemon is already enabled, and is dead Started: 15:41:54.253886 Duration: 152.304 ms Changes:
    ---------- ID: start_clamav_onaccess_service Function: service.running Name: clamav-onaccess Result: False Comment: Service clamav-onaccess is already enabled, and is dead Started: 15:41:54.406719 Duration: 167.456 ms Changes:
    ---------- ID: configure_clamav_clamdscan_cron Function: file.managed Name: /etc/cron.d/openmediavault-clamdscan Result: True Comment: File /etc/cron.d/openmediavault-clamdscan updated Started: 15:41:54.574677 Duration: 43.648 ms Changes: ---------- diff: New file mode: 0644
    ---------- ID: configure_clamav_clamdscan_cron_script_c855889e-0b7d-4995-80b1-d464bdbb132b Function: file.managed Name: /var/lib/openmediavault/cron.d/clamdscan-c855889e-0b7d-4995-80b1-d464bdbb132b Result: True Comment: File /var/lib/openmediavault/cron.d/clamdscan-c855889e-0b7d-4995-80b1-d464bdbb132b updated Started: 15:41:54.618612 Duration: 75.225 ms Changes: ---------- diff: New file mode: 0750
    ---------- ID: configure_clamav_daemon_logrotate Function: file.managed Name: /etc/logrotate.d/clamav-daemon Result: True Comment: File /etc/logrotate.d/clamav-daemon updated Started: 15:41:54.694121 Duration: 6.423 ms Changes: ---------- diff: New file mode: 0644 user: clamav

    Summary for orion.local
    -------------
    Succeeded: 16 (changed=8)
    Failed: 2
    -------------
    Total states run: 18
    Total run time: 4.088 s in /usr/share/php/openmediavault/system/process.inc:182
    Stack trace:
    #0 /usr/share/php/openmediavault/engine/module/serviceabstract.inc(60): OMV\System\Process->execute()
    #1 /usr/share/openmediavault/engined/rpc/config.inc(167): OMV\Engine\Module\ServiceAbstract->deploy()
    #2 [internal function]: Engined\Rpc\Config->applyChanges(Array, Array)
    #3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
    #4 /usr/share/php/openmediavault/rpc/serviceabstract.inc(149): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
    #5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(588): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatusDE...', '/tmp/bgoutput51...')
    #6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(159): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
    #7 /usr/share/openmediavault/engined/rpc/config.inc(189): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)
    #8 [internal function]: Engined\Rpc\Config->applyChangesBg(Array, Array)
    #9 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
    #10 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)
    #11 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)
    #12 {main}