OpenMediaVault on Proxmox

After a half-assed review of online information about NAS distributions, I chose OpenMediaVault because it's Linux-based (industrial-strength ones tend to be FreeBSD-based, which I'm less familiar with - that's something to learn another day), and it's got a good feature set without being too complex.

The installation (inside a Proxmox virtual machine) was text-based and classic Debian, although simpler and with less decisions than the default Debian install. WARNING: it will grab the entire HD and wipe it!!! After completing the install and rebooting, the console had some rather bad news for me:

Copyright (C) 2009-2015 by Volker Theile.  All rights reserved.

To manage the system visit the OpenMediaVault web management
interface via a web browser:

No interface(s) available

The default web management interface administrator account has
the username 'admin' and password 'openmediavault'.
It is recommended that you change the password for this account
via the web management interface or using the 'omv-firstaid'
CLI command.

For  more information regarding this appliance, please visit
the web site: http://www.openmediavault.org

omv login:

No interface(s) available?? A little research immediately turned up someone else with the same problem, but he "tried it again" and got in. So I ran ifconfig after logging in as root, got the IP address, and went to that address in a browser. And voila: there's the web interface and I can log in as expected. Better, it's available at omv.local where "omv" is the name I gave the server.

The next annoyance is that the web interface times out and logs you out after about five minutes. But it doesn't bounce you to a login screen, no: it leaves all your information up on screen (some of which could be somewhat sensitive) and overprints it with this rather loud black and red monstrosity that says "Software Failure. Press left mouse button to continue. Session not authenticated." To make sure it's extra annoying, it even flashes. What an incredibly stupid failure mode. This can, happily, be modified or turned off entirely in the interface by going to "System" -> "General Settings" -> "Web Administration" tab -> "Session timeout."

Proxmox - Adding an External USB HD

In the Proxmox host, I ran:

# lsusb

Bus 002 Device 002: ID 1058:0748 Western Digital Technologies, Inc. My Passport 1TB USB 3.0
...

Proxmox's documentation looks good until you start looking at it closely. The first step was the page on USB Devices in Virtual Machines -> Assigning Devices to VMs. So the advice was to run on the host qm set 104 -usb1 host=1058:0748. As recommended, I then rebooted. That didn't work (the HD wasn't visible in the OpenMediaVault VM after the reboot), so I took their next recommended step on the host:

# qm monitor 104
Entering Qemu Monitor for VM 104 - type 'help' for help
qm> info usbhost
Bus 2, Addr 2, Port 1, Speed 5000 Mb/s
  Class 00: USB device 1058:0748, My Passport 0748
Bus 1, Addr 5, Port 7, Speed 12 Mb/s
  Class e0: USB device 8087:0a2b
Bus 1, Addr 4, Port 3, Speed 12 Mb/s
  Class 00: USB device 041e:30dd, Sound Blaster X-Fi Go! Pro
qm> quit
# qm set 104 -usb1 host=1-7

I thought when I first listed info usbhost it had said that the HD was at "Bus 1" "Port 7" and that was why I made the qm set 104 -usb1 host=1-7 command, but now I'm not sure. Also note the bizarre inclusion of the Sound Blaster from my experimentation with Volumio on the same Proxmox server - I didn't ask for its presence in this VM, but seem to have it anyway ...

Another reboot, check inside the guest machine ... No joy. Then something prompted me to look for "pending" on the qm man page and I ran qm pending 104 and discovered that the two USB settings I'd added were listed not as "cur" (as were all other devices on this VM and other VMs) but as "new". Brain wave: they're lying, a reboot isn't sufficient. I turned the VM off entirely instead of just rebooting. On boot, the devices were listed as "cur" and an lsusb inside the VM showed the USB HD - but fdisk -l didn't see it. Don't know what prompted me to do it, but I decided the way to fix this was to edit /etc/pve/qemu-server/104.conf and change the line usb0: host=1058:0748 to usb0: host=1058:0748,usb3=yes and likewise change usb1: host=1-7 to usb1: host=1-7,usb3=yes. This could have been done through qm but I'm much more comfortable editing a config file. After a reboot, I have direct access to the HD in the VM.

Configuring OpenMediaVault

At this point, it appears the best path is to go into the OpenMediaVault interface, to "Storage" -> "File Systems" (not - as I first guessed - "Storage" -> "Physical Disks"), where I was able to mount the available partition from the new disk. The next step is "Services" -> "SMB/CIFS" (at least if you want to add the storage as a Windows share), where you go to the "Shares" tab and hit "Add". I also went into the "Settings" tab and changed the "Workgroup" name to "OMV" from "WORKGROUP" because Volumio is already using that(! I didn't know it had a share, and I'm not sure I think it should be sharing anything ...). And you have to check "Enable" to turn the whole thing on. So now nmblookup -S OMV shows me that something is going on on with the OMV workgroup. (I needed the smbclient and smb-common-bin packages under Debian to use most of the Samba-related commands.) And here's what looks like a good utility:

$ nbtscan 192.168.0.0/24
Doing NBT name scan for addresses from 192.168.0.0/24

IP address       NetBIOS Name     Server    User             MAC address
---------------------------------------------------------------------------------
192.168.0.0        Sendto failed: Permission denied
192.168.0.107       VOLUMIO          <server>  VOLUMIO          00:00:00:00:00:00
192.168.0.112       OMV              <server>  OMV              00:00:00:00:00:00
192.168.0.255      Sendto failed: Permission denied

Be warned that OMV -> "Access Rights Management" -> User -> "Users" tab -> "Add" actually adds real system users - I assumed the users created there were just for the OMV services. With a working user account on the OMV server, I can do this:

$ smbclient -L omv
WARNING: The "syslog" option is deprecated
Enter giles's password:
Domain=[OMV] OS=[Unix] Server=[Samba 3.6.6]

        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (omv server)
        maindisk        Disk
Domain=[OMV] OS=[Unix] Server=[Samba 3.6.6]

        Server               Comment
        ---------            -------
        OMV                  omv server

        Workgroup            Master
        ---------            -------
        OMV                  OMV

To try to connect:

$ smbclient \\\\OMV\\maindisk
WARNING: The "syslog" option is deprecated
Enter giles's password:
Domain=[OMV] OS=[Unix] Server=[Samba 3.6.6]
smb: \> ls
.                                   D        0  Sun Nov  6 18:38:25 2016
..                                  D        0  Sun Nov  6 18:38:25 2016

                1696456700 blocks of size 1024. 172281236 blocks available
smb: \>

I can log in with either the new user "giles" password - or a blank password. Either way, with the current settings, I can modify the share. Oops - I meant for guests to be read-only. Still working on that. I also expected there to be content there because there was on the original drive, but OMV creates a new local subdir with the name you specified (I thought it was just the share name, but it's both share name and dir name). Easy enough to move the content I expected to see into the subdir (have to log into the console of the OMV VM to do that).