Beiträge von Cubytus

    Already saw that with some cables I had repaired myself with just a blade and a screwdriver.


    If you need to repair network cables, even a basic RJ45 cable tester will tell if there's a broken wire inside. Whenever a wire breaks or has a loose contact, the NIC falls back on 3 pairs, which reduces maximum speed to 100Mbps AFAIR.


    If you need to regularly make your own cables, get a decent crimp tool and cable tester. No need for expensive equipment.

    Hi to all,


    as I attempted to solve a pesky DHCP-related bug and a SSH login being refused, I had to restart a WD MyCloud Home, running OMV6.

    There's also an external HDD attached to the USB3.0 port that I intend to use for another test. This drive is formatted as ext4 (AFAIR) and is self-powered, so there isn't any power draw concern, nor any formatting issue (it wouldn't be important on boot anyway)


    First trying to reboot, the drive span up, then down after a few seconds, giving off a loud click (the kind when heads park, not the same as a dead drive)


    I then disconnected the external HDD, and the MCH finally booted properly.


    So this is my first question: why would an external HDD prevent the MCH from spinning up?


    After a successful boot, I then attached the external drive, went to the Storage > Drive menu, manually searched for the HDD and there it appeared as sdb.

    Going down the menu to File system, I then clicked on "mount", but it keeps on loading something… Not sure what, but my drive just doesn't appear.


    And here's the second question: why my external drive isn't readily shown despite being formatted in a supported filesystem?


    And last but not least: still going down the menu in Storage > SMART > Devices, the right pane takes ages to be filled. In fact, it never completes.


    A hint: below the "alarm bell" menu, there are many tasks running in the background, but OMV doesn't show any detail when an alert it clicked. I can only stop it.


    Here's the "syslog" file as I type this post: https://bin.idrix.fr/?bdd9e0de…1rnLzpURBhFCShAmvruMyPbPA

    Yes if you can't put them in a subnet.

    Good to know, thanks. I'm still occasionally trying to find the "right" way to assign static DHCPs, though it isn't a priority.

    The link on the form does tell you what you can enter. The regex to check all possible options would be a pain.

    Hm, the man page only lists how to specify hosts, not of separating them by a comma is allowed or not. I must have been confused by the showmount --exports output syntax. Instead of a full-fledged regex test, just test for the known-non-working syntax? Or even cruder, make the statement more specific:

    Clients allowed to mount the file system, e.g. 192.168.178.0/24. Please check the manual page for more details.
    Clients allowed to mount the file system, e.g. an IP range 192.168.178.0/24, or a single client 192.168.178.16. Please check manual page for more details.

    And now you know the difference between a single developer product and one that hundreds of people work on. It is hard to make everything perfect.

    I should have paid more attention. Even if making an NFS share in Synology's DSM is more convoluted than in OMV, the description says it all:


    While DSM has a smoother learning curve and higher integration, especially with commercial services, advanced functions tend to be hidden from view and harder to access. Some of them only available in the command line. OMV is harder to learn as so many advanced options are shown right away and there are not many suggestions, but the resulting configuration should be more precise.


    Two different approaches to the same problem. If I didn't have a Synology and wasn't given an old single-disk NAS (not compatible with Debian), I probably would have used OMV as my main NAS OS. 8)

    Admittedly, I relied on OMV's GUI to alert me if there was any syntax error. There wasn't, so I assumed 192.168.1.15,192.168.1.10 was equally correct as 192.168.0/24.


    I don't want to allow all LAN clients to connect, and the idea of reassigning static, contiguous DHCP IPs across the entire LAN sounds like an unnecessary headache (Mix-and-match environment of old and new Mac OS X, Windows, buggy network printers, custom Linux, wired and wireless connections… plus the virtual Linux and Windows used for testing purposes)


    Should I repeat the share for each specific client I want to allow?


    Update: I tested that as I was typing, and indeed, it works on the Synology-based client. That means the OMV GUI I was relying upon, in this specific case, didn't alert me of a mis-type.


    Performance isn't constant, though. The first 20GiB file I moved went pretty close to the maximum available from this single-disk NAS (47MiB/s), but the following one only reached 17MiB/s.

    Hi there,


    as part of my OMV configuration, I routinely use NFS sharing between servers, mainly because it has less overhead or authentications issues than SMB or AFP. My OMV is a stock configuration for a single-drive system (OS and data on the same physical disk), the other NASes are synology DSM and a custom Linux distro made for a handful of small NASes that used a proprietary OS.

    1. I started by creating a shared folder without authentication because it's intended as a "catch-all" drop folder when I need to empty another NAS in a hurry.
    2. I left the extra options as default subtree_check,insecure. Later on I can add the required ones as needed as I don't necessarily know right away which ones will be necessary
    3. I then included the other NAS IPs I want to export the folder to. For the sake of this configuration, I started by the IPs of two other NAS on my LAN.
    4. From the OMV command line, I can see that the shared folder is indeed present in the /etc/exports configuration file:
    Code
    # cat /etc/exports 
    # This file is auto-generated by openmediavault (https://www.openmediavault.org)
    # WARNING: Do not edit this file, your changes will get lost.
    
    # /etc/exports: the access control list for filesystems which may be exported
    #               to NFS clients.  See exports(5).
    /export/Descargas 192.168.1.15,192.168.1.10(fsid=f702dac5-ad07-4b72-8110-b2deb7a56977,rw,subtree_check,insecure)
    
    # NFSv4 - pseudo filesystem root
    /export 192.168.1.15,192.168.1.10(ro,fsid=0,root_squash,no_subtree_check,hide)


    From /etc/fstab, the shared folder can be seen, too:

    Code
    # cat /etc/fstab
    # UNCONFIGURED FSTAB FOR BASE SYSTEM
    /dev/sda19    /    ext4    defaults 0 1
    /dev/sda20    swap    swap    defaults 0 0
    tmpfs        /tmp    tmpfs    defaults 0 0
    # >>> [openmediavault]
    /dev/disk/by-uuid/02054f28-6a37-b05b-8105-af0cd39cd60e        /srv/dev-disk-by-uuid-02054f28-6a37-b05b-8105-af0cd39cd60e    ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl    0 2
    /srv/dev-disk-by-uuid-02054f28-6a37-b05b-8105-af0cd39cd60e/Descargas/        /export/Descargas    none    bind,nofail    0 0

    However, nothing is actually exported.


    From OMV:

    Code
    # showmount --exports
    Export list for wdmch:

    From one of the NASes (192.168.1.213 being the OMV-based NAS):

    Code
    # showmount --exports 192.168.1.213
    Export list for wdmch:

    I'm not sure why as the manual page isn't specific.

    Hi there,


    I'm attempting to follow wiki.omv-extras.org page to configure compose on OMV6. This is a needlessly complicated process for such a simple function, plus I worry about the overhead this will entail on what is essentially a SBC, but I totally understand why the OMV developpers wouldn't bother anymore with plugin maintenance.


    For the sake of this post, I'm starting from this tutorial (plus a few, undocumented steps) with what I assume is a stock OMV6 configuration.


    Sooo, on step 5 we are required to set the PUID and PGID to 1000, but it doesn't explicitely says we need to use the ones from newly-created appuser: Worse, a few lines down we read:

    Zitat
    Replace the values with the appropriate ones in your case.
    • (…)
    • You can see the values of user appdata in Users > Users in the UID and GID columns.

    There no such user as appdata. In fact, following these instructions up to step 4 only shows one user, the one we just created. Does it refer to appuser, then?

    Plus, the columns aren't shown by default; one has to use the "table" icon to find these.

    Then there's:

    Zitat

    In this case we don't need it since we have defined the DATA folder in the plugin GUI at Services>Compose>Settings. But if you need to define other different routes you can also do it here in the same way as the rest of the variables.

    What does the "it" refers to? The environment variables?

    Hi there,


    I used dleidert's scripts to attempt upgrading an older Virtualbox-based OMV installation from the 4.x branch to the 5.x branch, at least to evaluate how smooth this would run before running it on live hardware (a WD My Cloud Home, to be specific). Not so smooth, it seems. After a reboot, the WebGUI denies entry, and `omv-firstaid` doesn't help


    The sript half-works and couldn't find a path to upgrade from Stretch, now EOL, for many components (404 error), and when it does, there's no release file available anymore. I edited the source files in /etc/apt/sources.list.d/ to point toward the Debian archive whenever possible, but it still fails to complete upgrade.


    Not sure how I'd get it out of this state…

    For regular updates and if you're used to it, it doesn't take more time then 1-2 minutes.It's like: Stop server, download and extract new version, run upgrade script, start server

    That's all fine and dandy on a locally-hosted OC installation, but completely impossible on a shared hosting people may use for availability reason.


    The first or second command line for an upgrade, according to OC's manual, is:


    sudo -u www-data php occ maintenance:mode --on


    There's no such thing as sudo on a shared hosting, or the provider has more serious problems than supporting an outdated version of OC.

    Hi there,


    Since a few days, I am attempting to reinstall OMV 2.2.x on a Raspberry Pi B. The intent is to first install an up-to-date version on the SD card, set up the RTC correctly (was a long process, but finally did it), then clone it to a USB SSD and switch the /boot/cmdline.txt to point toward the SSD partition.


    However, OMV now refuses to apply one change (I don't remember which one) and gives off error #4000:



    Setup is unremarkable: updated rasps-config to the latest version, corrected memory split to only leave 16MiB to the GPU, in addition of the modifications required for RTC functionality. Plugins Netatalk, CUPS and WebDAV installed, but not activated (yet).


    Tested: cloned the mmcblk0p2 partition to the /dev/sda1 on the SSD with command line:
    rsync -avxS / /media/one_SSD_UUID.
    Pointed /boot/cmdline.txt to it.
    Result: nginx doesn't run.
    Pointed back to original mmcblk0p2:
    Result: nginx runs, but can't apply the modification.


    How would I solve this annoying and seemingly random issue? If possible avoiding the tedious RTC config, update, upgrade, install process.

    I disagree with your disagree.Seafile is much faster, (full WAN/LAN instead of 1.8kbit/s with OwnCloud) full encrypted and such stuff. For using it as a Cloud, what it is, it is much better than NC/OC. For CalDav and such stuff you can use different things.

    Does it include easier updates than OC? OC isn't exactly automated in this regard and requires more manual work than other comparable PHP-based framework.


    Fully encrypted?


    Considering the world we live in, I think anything non-encrypted on OMV should be quietly abandoned.

    Not exactly a plugin, more an installation method:


    Name-branded NASes using a single disk sometimes have a "fake RAID" setup for their system files. This way, if something goes wrong, the user only has to reset the NAS to bring it back to a working state, no manual /lenghty flashing of a disk image is required.


    Or add GRUB in the standard installation so one could boot on a "debug" partition, much like Ubuntu does. (DK if this is already implemented as I run OMV headless most of the time.)

    Sorry to say but I think you need to give up your dream of a smooth running OMV install on this thing. I have a Qnap ts-451 that runs regular 64 bit (amd64) OMV 3.x and it is wonderful.

    I'm jealous. Being cash-strapped at the present time I have to choose between a completely silent setup (i.e. SSD) OR a recent Pi, but not both.


    Would a Banana Pi be powerful enough for OMV 3.0?


    Still wondering if it would be possible to upgrade the internals of a regular Qnap firmware and keep their low-requirements GUI.

    Hello there,


    I used the omv-upgrade command in OMV 2.2.13 to upgrade to the latest version, since there was no version 3.0 made for RPi B, as I understood. I put a hold on php5-pam as required on the Raspberry Pi B model.


    However, Nginx doesn't seem to start:


    I get

    Code
    service nginx status
    ● nginx.service - LSB: starts the nginx web server
       Loaded: loaded (/etc/init.d/nginx)
       Active: active (exited) since Fri 2016-11-11 20:43:54 CST; 1s ago
      Process: 1214 ExecStop=/etc/init.d/nginx stop (code=exited, status=0/SUCCESS)
      Process: 1177 ExecReload=/etc/init.d/nginx reload (code=exited, status=0/SUCCESS)
      Process: 1278 ExecStart=/etc/init.d/nginx start (code=exited, status=0/SUCCESS)

    I am not sure what this means, but I tried to stop / start the service, to no avail. There's no port 80 open on doing a port scan, and no web GUI displayed.
    On plugging in the TV, it still reports OMV 2.2.13 version.
    Configuration: RPi B running off USB HDD, RTC installed. Software configuration, except for running off the HDD, is stock 2.2.13 OMV.


    If that is any helpful, I don't see the omv-* utilities anymore, only omv-mkgraph is available.


    How would I solve this issue?

    Would there be a way to work around this issue so floating points operations are avoided as much as possible?


    I know it's kind of strange since non-floating point CPUs have almost disappeared.


    Does that means Debian has been compiled for armel, but not php5-fpm?

    Hmmm, the top command yields


    top - 13:17:25 up 2:16, 1 user, load average: 0,88, 0,31, 0,20
    Tasks: 86 total, 6 running, 80 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 95,3 us, 4,1 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 0,6 si, 0,0 st


    while the interface is displayed.


    wa seems nil


    There's no iostat here.


    iotop yields:
    Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
    Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
    TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
    1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
    2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
    3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
    5 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]


    Not sure if indeed CPU is too weak (I have OMV 2.0 on a RPi 1 rev B that has issues, but nowhere as bad as this board). What is your hypothesis on this?

    I finally got the OMV-Extras.org plugin installed, and managed to activate the flashmemory plugin, between error boxes. As SSH access was available and working, I also edited fstab like flashmemory-plugin instructed, saved, rebooted, and did omv-aptclean. This was rather long, about 10 minutes to complete execution.


    But it's not really faster overall, and, accross reboots, ports for SSH and the Web GUI may or may not open, and the serial console would or wouldn't let me log in (stays frozen at the "login: prompt").


    Using htop, I see the CPU stays at 100% with very high load numbers (5 and above), all caused by the webgui itself (multiple instances of php-fpm: pool openmediavault-webgui).


    I don't know if this can be helpful, but the OMV engine itself rarely takes more than 10%.


    Perhaps the issue on this low-power system comes from php-fpm configuration? Starting too manu child processes?

    Indeed it doesn't seem to do much, except putting a high load on the CPU while OMV interface is loaded (above 6).


    How would I turn off monitoring and install this plugin from the command line, even the serial interface, if possible? OMV's web interface is currently unusable due to these issues. I am also curious to know what would the flashmemory plugin would change, since the OS and OMV are running off a regular HDD