Posts by carriba

    Thank you for the feedback on this and do appreciate having forwarded the "What's all this with USB?" article.


    It is not my intend to use any RAID setup with disks hanging on a single USB cable or hub. Though, for educational purposes it does merit a mention on how RAID can be setup with any kind of disks setup.


    I stop here for now on this topic ;)

    The fact that this function does not exist is not because it cannot be implemented, it is designed that way precisely to avoid problems. Are you sure you need Raid? Do you know that Raid is not a backup? Do you have a separate backup of your data? If you continue with this you will need it.


    The RAID function does exist on the OS level. Yes, I know that RAID is not a backup and am not using it for this purpose.


    Is this a workaround for the above said? There is no "undocumented" feature available for OMV to still configure a RAID for a bunch of USB disks?

    If you are using an unsupported release, you will have to be creative. Most disaster recovery won't involve a fresh install. It will be restoring a backup image.


    Thank you for your feedback. A disaster recovery plan also considers a fresh installation and applying the necessary configuration settings to bring a platform back to its original state of operation.


    Debian Stretch is still in an EOL LTS release as reviewed back some time ago, and, as such, OMV 4.x ought to be supported as well.


    A re-installation ought to resolve my particular situation. This said, I will indeed spend some time and validate OMV 5.x in a test platform soon.

    I went ahead with a bare metal install with OMV 4.x under Raspbian Stretch as my previous platform was running with this version and it goes faster for me ;)


    Thus, on the terminal prompt fired the command:



    Then I fired the command:


    Code
    sudo sh -c 'apt update ; apt --allow-unauthenticated install openmediavault-keyring ; apt update'


    And I got the following output:



    To me it looks like it is a matter to get access to the public GPG key. Is it possible to obtain access or enable the installation through other means? ;)


    Otherwise, how can you do a disaster recovery when you have been using OMV 4.x all the time? :rolleyes:

    Due to installation challenges of OMV 5.x under Raspberry Pi OS Buster, I thought I give another try and reinstall OMV 4.x under Raspbian Stretch.


    Are there any installation guides on how OMV 4.x can be installed under Raspbian Stretch? (The original OMV 4.x images are no longer available.)


    I have found a pointer with the article titled Installing OMV 4.x under Raspbian Stretch on how the installation can be prepared and another note titled Installing OMV Extras for OMV4 under Raspbian Stretch on how the Extras can be installed.


    Is there anything else that I may need to observe?

    I have rebooted the device with a "sudo shutdown -r now ; exit", logged in again and relaunched the installation again as above, and this time the installation of the "nginx-full" package worked fine :).


    Here an extract of the output of the transcript on my terminal:



    The installation script moved forward, however I lost connection to the terminal during the installation step where the script was configuring network interfaces.


    When I tried to log in again, and even again after a power recycle, I could no longer login to the device, always getting an "Acess denied" message despite supplying the known login name and the correct password =O.


    I powered the device off and on again (by unplugging the power cord and plugging it in again), still no luck: I can no longer login to the device ;(.

    I started with a a fresh new image of the latest version of the Raspberry PI OS Buster, and have followed the online guide "Installing OMV", next to firing the OS packages repository updates also the commands:


    Code
    sudo rm -f /etc/systemd/network/99-default.link
    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash


    However, the installation fails with an error message when processing the package "nginx-full" ;(.


    Here the installation transcript with the relevant parts as displayed on my terminal:



    Double-checking with the "journalctl -xe" command for further error messages, I am getting the following output:



    Thus, not sure if or whether any latest potential OS updates may break the installation. Do welcome any pointer(s) that may allow me troubleshoot further on above observed issues :/.

    [...] And once Debian stretch updates stop, you should not be using an unsupported distro let alone and unsupported version of OMV.


    It did not mention anything about Debian Stretch. Sure, once the underlying OS is no longer supported, then most likely the original OMV version introduced for this Linux OS version is maybe no longer supported either. That's clear.


    Please keep this repository up and running for OMV 4.1.36-1 (Arrakis). It is not about not willing to upgrade or use the latest version, it is simply that a running system like OMV 4.1.36-1 (Arrakis) should stay running using its best hardware today.


    Thank you ;):thumbup:

    I'm using OMV 4.1.7-1 (Arrakis) and when checking today for the latest available RPM updates for my NAS box, it seems now I have the choice of 2 different versions as outlined with:


    user@nasbox:~ $ sudo apt list --upgradable -a
    Listing... Done
    openmediavault/arrakis,arrakis 4.1.28-1 all [upgradable from: 4.1.27-1]
    openmediavault/now 4.1.27-1 all [installed,upgradable to: 4.1.28-1]


    Which one shall I choose to update my current platform?

    Have a look at my posting "Windows 10 Creators failure to locate CIFS/SMB shares" to workaround the issue you're facing by simply launching the "Local Security Policy" tool, and under the branch "Security Options" and then under the option "Network Security: LAN Manager authentication level" , just change the settings from "Send LM & NTLM - use NTLMv2 session security if negotiated" to "Send NTLMv2 responses only".


    This did work for my PCs running Windows 10 Home and Professional back some time ago.


    To me it is clearly a Windows 10 issue as I can access the OMV's SMB shares with Windows 7, macOS High Sierra, Ubuntu MATE without any additional setup.


    This said, I do not need to make these kind of changes on my Windows 10 PCs when accessing a SMB shared drive residing on a commercial NAS. Thus, it could be also an OMV setup issue.


    Otherwise, setup an NFS server under OMV, and use NFS client that comes with Windows 10; see the "Setup NFS Client under Windows 10" guide on how to accomplish this. This is the approach I had to take for a PC running Windows 10 Enterprise as it is locked in a domain, and I could not perform above changes despite having admin rights.


    Hope this helps!

    Inspired by the "Stop using SMB1" article, it seems that I have found a solution or workaround to allow accessing again the NAS drive:


    Launch the "Local Security Policy" tool, and under the branch "Security Options" and under the option "Network Security: LAN Manager authentication level" , just change the settings from "Send LM & NTLM - use NTLMv2 session security if negotiated" to "Send NTLMv2 responses only".


    This did work for me and now have access to the OMV NAS storage platforms with SMB 2.0!


    Maybe it's worth to have a look at the OMV server side and explore other parameters...

    Let me recap the tests I've done, and the findings obtained:

    • Access to an OMV4 server using SSH terminal prompt and FTP shared folder is working fine with all Windows7, macOS, and Windows 10 operating systems.
    • Access to the same OMV4 server using CMB/CIFS shared folder is working fine with all Windows7 and macOS operating systems, however does not work with the Windows 10 operating system despite having followed all guidelines outlined with the HOW-TO "Connect to OMV SMB shares with Windows 10" post.
    • Accessing a commercial NAS platform with the Windows7, macOS, and Windows 10 operating systems is working fine. No issues at all, it even works with a Windows 10 PC!

    With the same Windows 10 PC, I can access a CMB/CIFS shared drive of the same commercial NAS platform without any problems, however it does not work with a shared drive declared within OMV4.


    With access I mean typing in the File Explorer address bar "\\192.168.0.10\" or "\\omv4server.local\" ,authenticate and see the shared drives of the bespoken server. For a commercial NAS server, it works fine with either addressing method, nothing to be changed there.


    When typing the address of the OMV4 server in File Explorer address bar, I'm getting a pop-up window asking for the credentials, however supplying the correct user and password information, I am always getting "The user name or password is incorrect" - why?


    Thus, either the SMB/CIFS on the OMV4 side needs to be tweaked or on a PC running Windows 10, especially when taking into consideration that SMB 1.0 is banned with the latest Windows 10 update, and who knows what else has been changed on the server &/or client side to patch security holes..

    Yes, this is correct. Either using the IP address or the host name to access the OMV4 server does not work for Windows 10 Enterprise and for Windows 10 Professional. I'm just getting a pop-up window asking for authorisation, however with the right user name and password supplied, I cannot gain access to the OMV4 server.


    For Windows 10 Professional the workgroup is correctly set as per the quoted HOW-TO in my previous post.

    No here a recap again on my yesterday and again today accomplished findings:


    Access to an OMV4 server using SSH terminal prompt and FTP shared folder is working fine with all Windows7, macOS, and Windows 10 operating systems.


    Access to the same OMV4 server using CMB/CIFS shared folder is working fine with all Windows7 and macOS operating systems, however does not work with the Windows 10 operating system despite having followed all guidelines outlined with the HOW-TO "Connect to OMV SMB shares with Windows 10" post.


    Accessing an other commercial NAS platform with the Windows7, macOS, and Windows 10 operating systems is working fine. No issues at all, it works with a Windows 10 PC.


    Now, to me it seems to look like a problem with OMV4's setup for CMB/CIFS sharing mechanism when using Windows 10.


    With the same Windows 10 PC, I can access a CMB/CIFS shared drive of the same commercial NAS platform without any problems, however it does not work with a shared drive declared within OMV4.


    Is there anything else I can check within OMV4 so that I can further nail down the origin of the problem?

    Yes, I can ping the OMV4 server, can SSH to it, and can also use the shared drives mounted with the FTP mechanism as described in previous post. Only the standard SMB share with Windows does not work.


    Can you point to the shortcut you're referring to, in case I missed something else here?