Posts by Spy Alelo

    Seems like we have bigger issues, deleting the file for me didn't fix it and now I get a lot of errors if I attempt to modify anything for notifications:


    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.