Beiträge von Spy Alelo

    Confirmed, the Previous Versions prompt is definitely serving the files off the SMB share when going through sub-directories, not the .snapshots directory:



    Files at the top level can be recovered. I can't figure out the why, the parameters seem correct for smb.conf and I've tried all types of combinations here. I can't really tell if this is a bug or a misconfiguration.

    And before anyone asks, browsing this data from a mapped share or URI yields the same result. Here it is doing it from the URI itself, same issue:



    I also thought this was a permission issue, but that's not the case. Whenever the snapshots are created, something's wrong with how the path is presented when trying to copy from them. I'm pulling my hair out trying to figure this out.

    So I got an interesting issue, and I couldn't find anyone else with the same problem after some searching.


    Long story short, I am trying to recover from a previous snapshot on a share. The volume is using btrfs, and the snapshot date is there. But when I try to recover it using Windows Previous Versions, I get "Item Not Found". It seems like is trying to recover from the original path, well since it was deleted of course it can't find it. It doesn't seem to be using the snapshots path to recover from, even though I can browse the data. See below:



    Eventually, I just used WinSCP to grab what I needed from the .snapshots folder. I replicated this issue on an external USB HDD that also has a backup of the same data with snapshots as well, and a 2nd OMV 7.6.0-1 server also with a btrfs volume and snapshots.


    As of note, if the data is actually not deleted from the share and you try to "recover" or open a file from within Previous Versions, it works but is not actually grabbing the data off the snapshots path but rather the actual live share.


    To replicate:

    1. Create a snapshot of the share

    2. Delete the original data

    3. Use Previous Versions on Explorer to recover

    4. Profit?


    I am not sure if this is a Samba Shadow Copy path issue or a misconfiguration on my end, but this is pretty bog standard stuff.


    Any input helps!


    I do happen to have one of these with the iLO5 enablement card. You can get the card for around $40 on Amazon.


    As far as the CPU is concerned, it is plenty powerful as a NAS and run Dockers or any other containers you choose. VMs are okay if you have plenty of memory, but not stellar.


    If you get one, I recommend a NVMe M.2 SSD on a low profile PCIe adapter for your boot drive. Any low cost solution will do, and this thing is rock solid in terms of reliability. And yes, is more efficient than your older setup.

    I read your comments on GitHub so I deleted and re-created the share with transport encryption, and now it works as you described.


    I am thinking is leftover from a long time ago, this box was originally running on OMV 3.xx and I've always upgraded to the next major release. I am not too surprised.


    Thanks for looking into it!

    openmediavault Release: 6.9.2-1


    I just noticed today that enabling "Transport encryption" per share wasn't working, and after some digging I concluded that the syntax for this option on this build of OMV is incorrect:


    Code
    server smb encrypt = required

    That syntax is for Samba v4.14.xx and above. The correct syntax for the version in OMV6 (v4.13.xx) is:

    Code
    smb encrypt = required

    I was able to get my shares encrypted properly once I added "smb encrypt = required" to my "Private Share":



    I raised issue 1605 on GitHub:

    SMB Encryption/ Transport encryption option has the wrong syntax · Issue #1605 · openmediavault/openmediavault (github.com)


    Once OpenMediaVault starts using Samba v4.14 and above, this would need to be revisited.

    I personally like to use the MDADM soft RAID for RAID5/6 instead of HPE's own solution (and I work for HPE!)


    My reason behind it is that MDADM is not hardware dependent, while a failure on your HPE SmartArray controller is the complete opposite.


    As far as performance is concerned, I don't see any advantages other than the writing caching features of the HPE controller (which is dependent on a battery that needs regular servicing) but it also depends on how much data you will be writing on a regular basis and how many clients will be using it.


    As long as you are aware of the limitations of hardware RAID and are able to get spare parts at any time, I don't see any reason to move away from it.

    I agree that your old server may have reached the point that is no longer a good option to keep feeding new drives to.


    As far as transitioning, I’d recommend a fresh install so you can take advantage of UEFI, and you will need UEFI anyway if you need to boot off a NVMe SSD which I strongly recommend.


    As of right now, Microservers only exist on Gen7 (yours), Gen8, Gen10 and Gen10+. Gen8 has been discontinued for a while and Gen10 was not a great replacement in my opinion since it lacks a lot of what made the Gen8 a great server.


    Gen10+ brings it all back, has more options and it is smaller. Definitely avoid a discontinued model if you can help it since UEFI is a big deal and this only started on Gen9 hardware. Gen10 as far as the Microservers are concerned.

    You have a couple of options. I would have to either convert towers to rack servers or use a shelf for towers in our racks. These shelves are not exactly cheap, but you may be able to find it used on eBay. Since the ML10 v2 is fairly lightweight, you can use 417705-B2 as long as your rack is deep enough for it.


    Or use a generic rack shelf and pad it with some packing foam, secure the tower to the shelve with a Velcro strap around it so that it won't move around (that's what I had to do sometimes).


    Buying a used server is not a bad idea at all, it all depends on what you want to do. If it is just for storage, I'd recommend the MicroServer Gen10+ which is relatively inexpensive even when new. It has x4 LFF bays, x4 Ethernet ports, and a PCIe slot. You can easily get that, add four very large SATA hard drives and get an inexpensive PCIe to M.2 NVMe adapter with a cheap M.2 NVMe for the OMV OS. Although it does have the iLO5 chip, you do have to purchase the iLO5 network adapter which if you shop around, you can get for less than $50.


    I got that server for myself and I have x4 10TB drives, for a total of 30TB of storage. Honestly, the small size, lower power consumption, low noise and low heat that comes out of it really made it totally worth it for me. Plus, it looks pretty!

    Hi there.


    Normally, when RBSU cannot communicate with iLO is due to a misconfiguration or a corrupt iLO firmware. There are a few things you can try out:


    1. Enter RBSU (F9) during post, and reset RBSU to manufacturing defaults.
    2. If that doesn't work, and you already have OMV installed, install hponcfg and attempt a factory reset from the CLI with hponcfg /r
    3. If that also fails, completely turn off your server and remove the power. Then remove the CMOS battery and leave it out for an hour.
    4. Re-install the battery and power up your server again.

    Removing the CMOS battery will erase all the RBSU and iLO4 settings from the server. If this doesn't resolve the issue, is probable that iLO has a corrupted firmware EEPROM. This may require the motherboard to be replaced.

    I know right? Is so bizarre, I don't even know where to start on trying to figure this out.


    As you said, I don't see where it would generate this or even why.


    I did see an impact that this would have for me, and that's when using WOL. The app I use wouldn't be able to determine if the server is up since it has use the the physical MAC to power it up. I got scripts on another server that checks those things and powers it up to RSYNC files from one to the other, this will be a challenge.

    Hi all!


    I'm doing an early test of OMV 5.2.3-2 through an upgrade from version 4. I've been able to see a few issues along the upgrade and was able to fix them all, but something caught my attention.


    When creating my bond (I use 802.3ad LACP) I noticed that the MAC address gets auto-generated, instead of deriving it from the 1st NIC. Here's a snapshot I grabbed from iLO:



    The newly generated MAC is highlighted. I don't actually see any ill side-effect with this, other than the IP changing for those that use DHCP and maybe those that prefer to use the physical MAC (like me).


    Does anyone knows if this is by design and expected?

    Hello everyone!


    iLO4 2.70 has been released. Among the bug fixes, this new version has HTML5 support for the KVM console and works with any modern browser. Java or .NET are no longer required.


    To update iLO from its own interface, simply open the cp038075.exe with the 7-zip utility and extract the ilo_270.bin file. Then go to "Administration" and "Firmware". You can now upload the .bin file from there, is self-explanatory at this point.


    Updating your iLO will not cause any downtime on your server, it can be done live. This iLO4 update applies to all Gen8 and Gen9 servers.


    Gen10 servers already had HTML5 console support on iLO5 since version 1.20.

    So here's how you can make the SSD on the Microserver Gen8 OOD port bootable:

    • First, make sure that the Dynamic Smart Array option is turned on. You can enable it in the BIOS/RBSU settings (F9)
    • Start up the server, then press F10 during POST.
    • After POST, you should get three options to boot. Select "Smart Storage Administrator" (or SSA for short)
    • Select the storage controller, should be labeled as "Dynamic Smart Array B120i RAID"
    • Click "Configure"
    • Click "Create Arrays with RAID 0"
    • Select ONLY the drive that contains or that will contain OMV, then click OK and confirm YES. You do not need to create any more arrays/volumes.
    • On the list to the right, click on "Set Bootable Logical Drive/Volume"
    • Select the new logical drive you just created as the "Primary Boot Logical Drive/Volume", then click OK
    • You can exit the program, and restart your server

    And that's it! The server can now boot your SSD regardless of where is connected.


    For those that already had OMV in the drive and had GRUB elsewhere, you have to install GRUB back into your SSD for this to work.


    Although I've been able to add/remove the volume from being an array with RAID 0 and didn't lose any data, I recommend that you at least make a backup in the event something does happen. Is unlikely, but you never know.


    Also, make sure that "Hard Disk Drive" is the first one under the boot order. You can change this either with iLO under Virtual Media, or the BIOS/RBSU settings (F9).