Posts by markus-fried@gmx.de

    Hi,


    ok, I admit I have not looked closely at drives and file systems for a while, my box has been running for some years and survived all the OMV migrations/updates I put up for it.


    Since my drives are now >6 years old I thought about activating automatic notifications especially for SMART events, which I did yesterday. Tonight I got a mail "A DegradedArray event had been detected on md device /dev/md/126_0"


    Looking at the GUI I'm not sure what to make of this, it says md125 is degraded (not 126)??



    Can you shed some light on what these partitions really are and whether the "degraded" warning is something to worry about?


    Best regards


    Mark.



    System looks like this:



    Code
    ARRAY /dev/md/OMV:MasterVault level=raid5 num-devices=3 metadata=1.2 name=OMV:MasterVault UUID=2925be41:fc40e814:1ba6b2a7:d48d94eb
    devices=/dev/sda,/dev/sdb,/dev/sdc
    ARRAY /dev/md/127_0 level=raid1 num-devices=1 metadata=0.90 UUID=6b872a8b:c0d8ae59:afc0f612:2c5b3870
    devices=/dev/sdd4
    ARRAY /dev/md/126_0 level=raid1 num-devices=2 metadata=0.90 UUID=1b692fd1:0b7d4871:90edcaab:235dd1c8
    devices=/dev/sdd2
    ARRAY /dev/md/125_0 level=raid1 num-devices=1 metadata=0.90 UUID=9eee4ce1:8f7bd9f8:d8323686:4d9c359d
    devices=/dev/sdd1

    Hi,


    I've been running miniDLNA for some years on my OMV box, accessing it from Noxon players and android devices to stream music from my NAS.


    Lately I've been trying to create some playlists to be served via miniDLNA, too. m3u-lists have been created and placed in a shared directory, media type for this share is "all". Rescan was forced in miniDLNA.


    Unfortunately miniDLNA refuses to serve these lists to my clients - neither the standalone boxes nor the Android or Windows players show the playlists.


    Is there a special trick to get miniDLNA to recognize playlists?


    Best regards
    Mark.

    Code
    ii libopenmpt0:amd64 0.2.7386~beta20.3-3+deb9u2 amd64 module music library based on OpenMPT -- shared library
    rc openmediavault 3.0.88 all Open network attached storage solution
    ii openmediavault-keyring 1.0 all GnuPG archive keys of the OpenMediaVault archive
    rc openmediavault-minidlna 1.1 all OpenMediaVault miniDLNA (DLNA server) plugin
    rc openmediavault-nut 3.2.12 all OpenMediaVault Network UPS Tools (NUT) plugin
    rc openmediavault-nzbget 1.6 all command-line based binary newsgrabber for nzb files

    this is what it gives me...

    Hi,


    today I tried an update from Stoneburner to Erasmus with 'omv-release-upgrade'


    The update process fails with following error:



    Now the OMV Webgui is inaccessable - I get a 403 page. Tried to restart nginx to be sure - no effect.


    Syslog shows this and others:


    Code
    Sep 19 09:52:43 mediavault monit[5106]: 'nginx' start: /bin/systemctl
    Sep 19 09:53:08 mediavault dbus[3478]: [system] Unable to reload configuration: Failed to open "/etc/dbus-1/system.conf": No such file or directory
    Sep 19 09:53:08 mediavault dbus[3478]: [system] Unable to reload configuration: Failed to open "/etc/dbus-1/system.conf": No such file or directory
    Sep 19 09:53:08 mediavault dbus[12694]: [system] Reloaded configuration
    Sep 19 09:53:08 mediavault dbus[12694]: [system] Reloaded configuration
    Sep 19 09:53:08 mediavault dbus[3478]: [system] Unable to reload configuration: Failed to open "/etc/dbus-1/system.conf": No such file or directory



    and these continously on a minutely basis:


    Code
    Sep 19 12:23:15 mediavault monit[5106]: 'nginx' failed protocol test [HTTP] at INET[127.0.0.1:443] via TCPSSL -- HTTP error: Server returned status 403
    Sep 19 12:23:15 mediavault monit[5106]: 'nginx' trying to restart
    Sep 19 12:23:15 mediavault monit[5106]: 'nginx' stop: /bin/systemctl
    Sep 19 12:23:15 mediavault monit[5106]: 'nginx' start: /bin/systemctl
    Sep 19 12:23:16 mediavault monit[5106]: 'collectd' process is not running
    Sep 19 12:23:16 mediavault monit[5106]: 'collectd' trying to restart
    Sep 19 12:23:16 mediavault monit[5106]: 'collectd' start: /bin/systemctl
    Sep 19 12:23:46 mediavault monit[5106]: 'collectd' failed to start (exit status 0) -- no output



    What's worse, SMB shares are gone - so no access to my files :-(


    Does anybody know what this error is and how to fix this?


    Best regards


    Mark.

    ;-) thanks anyway, just in case here is the output of 'blkid'



    thanks for you input -I already did a fs check - no errors - it's just that it won't get mounted on startup :-(


    When I try to mount the RAID manually I get the following error:




    Code
    Error #6000:
    exception 'OMVException' with message 'Failed to mount 'fefa03a4-f295-4b64-b7ad-49dba9101cc8': mount: can't find /media/fefa03a4-f295-4b64-b7ad-49dba9101cc8 in /etc/fstab or /etc/mtab' in /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc:931
    Stack trace:
    #0 [internal function]: OMVRpcServiceFileSystemMgmt->mount(Array, Array)
    #1 /usr/share/php/openmediavault/rpcservice.inc(125): call_user_func_array(Array, Array)
    #2 /usr/share/php/openmediavault/rpc.inc(79): OMVRpcServiceAbstract->callMethod('mount', Array, Array)
    #3 /usr/sbin/omv-engined(500): OMVRpc::exec('FileSystemMgmt', 'mount', Array, Array, 1)
    #4 {main}


    omv-mkconf fstab did not change the situation either.


    Mark.

    Hi guys,


    I've got 3 WD SATA drives configured into a RAID5.


    Today had a power outage the battery kicked in and shut the server down.


    When I restarted later my data volumes were gone.


    I can see the RAID5 as clean in the OMV GUI, but the file system on it can't be mounted.


    Any idea?


    Best Regards


    Mark.

    Hi,


    on my N54L ntp is active in OMW GUI but time is always off. etc/ntp.conf looks like this:


    This is the default that came with OMV installation.


    I read some posts about problems with systems like Banana or RaspPi not being able to sync with NTP, but I don't understand what's the problem with my N54l installation.


    Any ideas?


    Kind regards
    Mark.

    yes, both target drives are using ext4


    Code
    /dev/sdd3 on /media/ab855e11-d4b3-4d1e-8dd8-5487cb6d9518 type ext4 (rw,noexec,relatime,user_xattr,acl,barrier=1,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group,_netdev)
    /dev/sdf1 on /media/9233e731-35e8-44a1-acda-494a8e782c5b type ext4 (rw,noexec,relatime,user_xattr,acl,barrier=1,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group,_netdev)

    CPU is a AMD Turion II Neo N54L with 8GB RAM, rsync fully uses both cores.


    Disk transfer rates on internal spare drive and external eSata are identical.


    I did some more tests, all with a complete backup in place which is used for the link-dest argument of rsync.


    My skript backups several directories, most of which contain a few hundred/thousand small/medium files with NO changes/modifications, but one directory contains 15000 photos of ~10MB each and another one keeps 80000 audio samples of similar size.


    Running my skript with the internal target is very fast - no changes, nothing to do.


    Running it with the eSata drive as target skips all files (since they are unmodified) in all source directories (including the photos) whith the exception of those in the Audio directory. So although those have NOT been modified either, rsync thinks it needs to process them anyway and unnecessarily shuffles around 800GB.


    Strange!