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:
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?
I'm having the same issue here that with a Windows 10 client I cannot access the Samba shares of OMV4 
I have followed the HOW-TO instructions "Connect to OMV SMB shares with Windows 10" and also modified the respective "Enable insecure guest logon" registry parameters, rebooted the PC, and still no luck to access the shared drives of the OMV4 server.
Have I missed anything else? Is there something that can be configured on the OMV4 side?
As a workaround I'm now mounting the shares using FTP as described with "Map FTP Drive in Windows". Not the ideal solution, however that's the only workable approach for now...
Use the URL provided above and again here for the OMV3 Raspberry Pi image file. It works for me just fine.
I have performed a new OMV 4.x installation and have added the line contents "OMV_APT_USE_KERNEL_BACKPORTS="NO"" at the end of file "/etc/default/openmediavault".
I then have fired the command "wget -O - http://omv-extras.org/install | bash" under the "root" shell prompt, and now every time I install a plugin, I'm getting the following output:
Processing triggers for openmediavault (4.1.12) ...
Updating locale files ...
Updating file permissions ...
Purging internal cache ...
Restarting engine daemon ...
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x762cc4b0>
Traceback (most recent call last):
File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x762cc4b0>
Traceback (most recent call last):
File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable
Done …
Is this something known that I can ignore in my daily operations with OMV 4? I believe, I am getting above output every time I install a plugin from the OMV Extras repository...
I have added OMV_APT_USE_KERNEL_BACKPORTS="NO" in the /etc/default/openmediavault file, and this allowed a smooth installation on the command line without any errors.
Thank you for the pointer !!
I will check now the OMV 4 application...
Followed the instructions under "Install OMV 4 on Debian 9 Stretch", which went fine apart from installing the "resolvconf" package beforehand, and OMV is running fine without any problems under this OS until today.
I followed the "Installation of OMV Extras" guide, installed beforehand the "dirmngr" package, and fired from the command line under "root":
However, after a while, I'm getting the following output of error messages:
What can or shall I do here? Seems that there are some hardcoded lines pointing to the native Debian 9 Stretch repository 
Why?
To come back again.
If above proposed download is not OK, then maybe another permanent one with the remark that OMV 3 for Raspberry PI is EOL, however Debian Jessie still has LTS until June 2020 and is still getting OS updates.
That's what I've done, and maybe in a rush, I must have missed the OMV 3 alternative download place in your previous post - please keep it intact if you don't mind 
Thanks!
Sorry, for coming back on this. I'm in an urgent need of the OMV 3 image for a Raspberry Pi 2. Where can I download it now as I do not seem to find it in the usual download place
Thank you for your suggestions! I checked the "dmesg" output and according to the logs, there seems to be no SD card corruption.
The PSU (5.2V & 3.4A) I have, ought to be fine, as I have the same using for other RPI devices no kernel panics yet experienced on any of the devices. All external disks plugged are powered by separate PSUs, thus I expect no current drain from the RPI device itself.
This said, I like your "raspimon" script, and have installed and running, and keep an eye on the statistics being generated to see if it can give some insight on the internals on the operational behaviour of the RPi device.
Today, I've done the usual "sudo apt-get update ; sudo apt-get -y upgrade" on an existing Raspberry Pi server with Rasbpian Jessie as the underlying OS that I'm using as a NAS box with OMV 3.0.99.
Rebooted the device and connected with SSH and after a couple of minutes, I'm getting kernel panic error messages as outlined with attached transcript file raspberry_kernel_panic.txt and the device freezes or comes to a complete standstill. Have to unplug the PSU and then power it on again.
Any idea what this might be related to? From the cryptic output it seems to be a kernel error.
OMV 3 under Raspbian Jessie works for fine for the purposes you're describing here as an FTP server.
You can donwload its image file and flash it into SD card.
In my case also get the PlexMediaServer running fine. I have not tried the installation of OpenCloud for OMV yet, however skimming through the documentation, it ought to be independent of the version of OMV.
Resolved the issue by removing the "root" pointer in the environment variable $PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR in the file "/lib/systemd/system/plexmediaserver.service", and then removed the "Codecs link loop" found after the installation.
It seems to be working for now, and right: never update a running platform.
Thank you for all the pointers and guidance above, much appreciated!
Thank you for the pointer above. I went even further and fired the following command:
sudo apt-get -y install openmediavault-omvextrasorg
which indeed did install the package, and when launching the OMV Web GUI, I can see the the "System -> OMV-Extras" panel now.
