Posts by vinntec

    When I first started using OMV some time ago, I moved all my iTunes files onto OMV but listen to music on Windows 10 main computer using the iTunes app. Everything worked fine but in the last few months, I have noticed that the music pauses then continues as if something can't keep up.

    To install, all I did was move all the iTunes media files to the OMV server and pointed "iTunes media folder location" to there \\NAS-MEDIA\music\iTunes\iTunes Music. I am not using the iTunes plug-in as I cannot find anything about how it is supposed to be used.

    The network is all 1.0 Gbps Ethernet and OMV is running on Odroid HC2 with current version 4.1.23-1.

    Is there a better way to do this, or can anyone suggest things to check if this should work fine?

    Yep, looks fine to me. One known problem of the new image is that Hardkernel's support repos for their Cloudshell 2 stuff do not work. At image creation time I got

    E: Unable to locate package odroid-cloudshell
    E: Unable to locate package cloudshell2-fan

    But honestly don't care. Up to Hardkernel to add instructions to their wiki to add this stuff manually later.

    From my point of view the XU4/HC1/HC2 image is ready. Thank you!

    As far as I can see these both relate to the Cloudshell cases for the XU4 and won't affect anyone else. Installing them is mentioned in the Cloudshell Wiki and that should be enough hints for most people who happen to have one and are installing OMV4. You might mention it in the readme?

    On the two I recently installed, one of them kept losing the network connection until I "wiggled" the cable slightly. Since then they have both run fine, no problem. Just look for the yellow LED (there is only one) coming on which will tell you that you are on the right track (of course this assumes the other end is enabled).

    As far as the difference in Ethernet port is concerned, this is due to a change to the use of "Predictable Network Interface Names". Not sure why they didn't both use eth0 or the new names, but that's a different question.

    You can force the system to use either - the HC2 only has a single Ethernet port so I preferred to use eth0 format. You do this by providing a boot parameter, which used to be done in /boot/boot.ini, but if you look in there it says to make changed to /boot/armbianEnv.txt (which didn't exist yet in my case). After some help on the various forums, I determined that I needed to add this line:


    Rebooted - and first time it had gone back to using DHCP so I had to login to delete the old adapter, add it again as eth0 then reboot. I put the same change on the other one to be consistent. Obviously I could have done it the other way around and set both of them to 1 to use the new names.

    As I had carefully documented what I did, I went back to the basic working OMV4 image and redid all the customisation. OMV looks fine now, except for the Ethernet port:

    Network-->Interfaces - on system 1 the Ethernet interface is eth0, on system 2 it is still enx001e06328f51.

    I think I will put this remaining problem on the Odroid forum. although everything appears to be working fine. No idea what went wrong first time around!

    This is really weird. I have 2 x Odroid HC2 and installed the current image and upgraded that to OMV4. Image saved and this was used to create the final SD cards for both HC2. So both started with a basic working OMV4 ready for customisation. However today I got on to configuring the second one and realised that it looked different to the first.

    Dashboard - on system 1 the services are marked Enabled and Running with green spots, but on system 2 the Enabled column is blank and Running has the old look.
    Rsync Jobs - on system 1 there are green spots in the Enabled column, but on system 2 the Enabled column is blank.
    SMB/CIFS Shares - on system 1 there are green spots in the Enabled column, but on system 2 the Enabled column is blank.
    Network-->Interfaces - on system 1 the Ethernet interface is eth0, on system 2 it is enx001e06328f51.

    Both systems are working absolutely fine apart from this. I suspect it is something obvious but can anyone help?

    As i know, openmediavault upgrade/update automatically at first boot.

    If this not happens, you can do it from the gui, so why use ssh?

    No - the installation updates the current version OMV_3_0_92 during installation. You have to do the conversion to OMV4 yourself - which you can only do from SSH.

    I have just installed OMV on 2 x Odroid HC2 and upgraded to OMV4 with very few problems running completely headless from the start. Basically:

    • Download the latest image and burn to SD card (it fits easily on 8GB).
    • Fire up OMV using that.
    • Find the IP address of the HC2 and login to OMV so you can allow root login from SSH (in SSH settings).
    • Login from SSH using default credentials (root/openmediavault).
    • omv-release-upgrade and leave it to run. It takes a while depending on various things.
    • If all OK so far, apply any upgrades (there were only a few).
    • Probably reboot about here.
    • Configure OMV on your HC2 how you like.

    Does this help?

    With this latest OMV image also nand-sata-install to transfer the OMV installation over to a HDD or SSD is finally working. But you should keep in mind that this will prevent disk sleep with HDDs (please check also the JMS578 spindown firmware issue that is about to be resolved soon). And you must keep in mind that you need to create partitions on a connected disk first otherwise OMV won't allow you to use this disk also for data later! So a good recommendation could be to use 2 partitions: 10GB for the OS and the rest for data.

    After running OMV2/3 on RPi2 and RPi3 for a few years, I am waiting for delivery of a pair of Odroid HC2 to replace them (I might have gone with Rock64 Transformer if they had one that took 3.5" drives). I have ordered 4 x decent micro-SD cards to do the booting (2 live + 2 hot spares). Now the 10 million dollar question is "which is better - to run OMV from the SD card and let the data disk sleep when not in use, or run OMV from a partition on the data disk and let it spin all the time day and night and just use the SD card to boot?"

    There is a video in another thread which gives good information about this Which energy efficient ARM platform to choose?. There is a second video which adds Odroid HC1 to this (and by implication HC2 although that will use a hard disk).

    I recently rebuilt my OMV3 setup on RPi3 as I wanted to get rid of the software RAID of my original - so instead I now have 2 x RPi3 OMV3 each with a hard disk - one which is for backups, and the other for media. They also mutually back each other up. It all works brilliantly if a little slower than it could.

    However an upgrade to OMV4 will be needed soon at about the same time as my birthday! I am thinking seriously about moving to 2 x Odroid HC2 (to reuse the 3.5" disks on the current RPi3 NAS).

    Have a look at the videos of the 5 boards running OMV (including RPi3) and see what you think.

    From the process (under Windows is "Windows"), you can create a server Shortcut on the Windows 10 desktop as @porkenstein did. For convenience, right click the Shortcut icon and pin it to Quick Access and Start. If you've set SMB2 "on" and there are no firewall issues, shortcuts should work in nearly any circumstance. It may not be as convenient as network browsing (depending on preference) but it's much more reliable.

    BTW: This problem with Win10 also affects Windows Server (long running Windows thread) so buying M$ Server Essentials and/or setting up a Windows domain may not work any better than OMV.

    Done, works fine thanks.

    I have followed the instructions and everything is working fine without SMB1. The two Windows machines can see each other and their shares as normal, but they can't "see" the Linux shares. However, iTunes can find the music server no problem and I can mount any share I want using "map network drive", which seems to work exactly as browsing used to.

    As far as my problem with the laptop is concerned, I do the backup for this manually as weekly is sufficient. So this bypass works for me:

    • Check the mount point on OMV root (I use mount)
      // on /srv/6c12ad5d-36ad-44eb-95cb-6d6dc3c2b87f type cifs ...

    • Unmount the share using the “lazy” option (which means wait until it is not busy).
      umount -l /srv/6c12ad5d-36ad-44eb-95cb-6d6dc3c2b87f
    • Check file systems on OMV GUI - it should show as not mounted.
    • When the next backup is due, fire up the laptop then issue mount -a on OMV root, then check it is showing in OMV file systems in web GUI as mounted.
    • Run backups as normal.
    • Unmount as in step 2.

    Making this change to cmdline.txt to use PARTUUID made the boot work reliably with the HDD attached, although the SSD is still /dev/sdb afterwards but that doesn't matter.

    Code: /boot/cmdline.txt
    dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=c5ac05a5-02 rootfstype=ext4 elevator=deadline rootwait quiet

    However if I then change /etc/fstab to match then I get an error a-start-job-is-running-for-dev-disk-by pointing to the boot partition then a kernel panic.

    PARTUUID=c5ac05a5-01 /boot vfat defaults 0 2
    PARTUUID=c5ac05a5-02 / ext4 defaults,noatime 0 1
    #UUID=CE83-8CE1 /boot vfat defaults 0 2
    #UUID=ae708a4d-982a-4a20-965c-01ec7e1f32b3 / ext4 defaults,noatime 0 1

    Commenting out line 1 above caused it to boot and I could mount it from OMV no problem. This put this entry into /etc/fstab in the OMV section at the bottom:

    /dev/disk/by-label/boot /srv/dev-disk-by-label-boot vfat defaults,nofail 0 2

    Then I thought, why didn't it mount as /boot? Hang on a doggone minute, is there a boot folder on the root partition? Yes, but there is nothing in it. Hence the problem. Using UUID must have given the same error, but in this case OMV started up OK but I noticed it wasn't mounted later on.

    I created the boot and root partitions on the SSD by installing the current RPi image on SD card first, saving the image of the card (three partitions), then using Etcher to burn it onto the SSD. Just checked the other OMV and that is the same. Not an issue now I know.