Windows cannot access OPENMEDIAVAULT

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Windows cannot access OPENMEDIAVAULT



      This is the message I'm always getting: "Windows cannot access OPENMEDIAVAULT" when I try to access my folders inside OpenMediaVault-server on my windows 10 computers.

      On my first windows 10 laptop it didn't work. But on my old Windows 10 laptop (which wasn't updated for some years) it worked. But after updating the old laptop, it stopped working.
      So first I thought it could've been this: [HOW-TO] Connect to OMV SMB shares with Windows 10 and Microsoft Servers (thanks to @crashtest). My (old) MacBook can still reach it.

      but even after fiddling around, I couldn't get it to work!

      Anybody knows what the problem could be? And what I could do about it?

      PS: I'm a beginner in Linux and therefore also in OMV
    • From your previous thread, you might have an odd permissions issue.

      Try setting up a new share according to this Guide, starting on page 47 (in the current version) - Creating a SMB/CIF “Samba” Network Share. Name it "Test" or something like that. Follow through the set up, then see if you can access it, and copy files to it.

      Also note, if you leave your Win10 box up most of the time, it wouldn't hurt anything to reboot it while the server is up.
    • In general it's a good idea to try to see at which stage a connection attempt is failing. Is it an issue with service propagation/location (name resolution)? Or something with permissions? To nail this down you could try some steps on each Win10 host and compare:
      • In cmd.exe (or whatever the Windows command line is called these days) execute ping openmediavault
      • If this resolves to the IP address of your OMV box, then try to access \\openmediavault
      • In cmd.exe (or whatever the Windows command line is called these days) execute ping openmediavault.local
      • If this resolves to the IP address of your OMV box, then try to access \\openmediavault.local
      • If then you get the '"Windows cannot access ..." message the name resolution part is already resolved and it's about permissions or something else
      Also just like any Unix or Linux out there Windows has logging functionality (Event Log -- has been enhanced/fixed wrt SMB connection problems years ago). Why wild guessing when you can have a look what's going on?

      @macom: can you confirm that Event Viewer --> Applications and Services Logs --> Microsoft --> Windows --> SMBClient provides reasonable information with Win10?

      The post was edited 1 time, last by tkaiser ().

    • Pol de Lepel wrote:

      But after updating the old laptop, it stopped working.
      The update has probably turned off Network Discovery, in File Explorer select Network in the address bar type in \\<ip address of omv> if Network Discovery has been turned off a drop down will appear, select/enable Network Discovery. Your error is related to the most recent cumulative update for 1803, I had the same issue

      With the inclusion of wsdd in omv connections to omv shares should be straight forward, what version of W10? Home, Pro, Enterprise, Education. Also on omv under smb/cifs disable local master browser, this setting has issues with wsdd when wsdd is updated.
      Raid is not a backup! Would you go skydiving without a parachute?
    • tkaiser wrote:

      @macom: can you confirm that Event Viewer --> Applications and Services Logs --> Microsoft --> Windows --> SMBClient provides reasonable information with Win10?
      Might be worth a look.
      However I have one error listed which is mentioning that my server cannot be reached. For problem solving it is mentioned that this is not a SMB problem (!!!) but probably a network problem or a firewall problem. The server is currently swiched off ;)

      But for sure there is a lot of information provided that might be helpful to track down an issue.
      Odroid HC2 - armbian - Seagate ST4000DM004 - OMV4.x
      Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 - Intenso SSD 120GB - OMV4.x
      :!: Backup - Solutions to common problems - OMV setup videos - OMV4 Documentation - user guide :!:
    • 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!

      The post was edited 2 times, last by carriba ().

    • New

      First, sorry for the late answers, but it was a busy week for me.
      But it still doesn't work :(

      crashtest wrote:

      From your previous thread, you might have an odd permissions issue.

      Try setting up a new share according to this Guide, starting on page 47 (in the current version) - Creating a SMB/CIF “Samba” Network Share. Name it "Test" or something like that. Follow through the set up, then see if you can access it, and copy files to it.

      That's how I installed the shares already with everything as public as possible.

      crashtest wrote:

      Also note, if you leave your Win10 box up most of the time, it wouldn't hurt anything to reboot it while the server is up.

      I restart a lot on my testing windows 10 laptop, although it doesn't has an SSD :|

      tkaiser wrote:

      In general it's a good idea to try to see at which stage a connection attempt is failing. Is it an issue with service propagation/location (name resolution)? Or something with permissions? To nail this down you could try some steps on each Win10 host and compare:
      • In cmd.exe (or whatever the Windows command line is called these days) execute ping openmediavault
      • If this resolves to the IP address of your OMV box, then try to access \\openmediavault
      • In cmd.exe (or whatever the Windows command line is called these days) execute ping openmediavault.local
      • If this resolves to the IP address of your OMV box, then try to access \\openmediavault.local
      • If then you get the '"Windows cannot access ..." message the name resolution part is already resolved and it's about permissions or something else


      The ping works fine. Already tested it before. And the latency is always 1ms or lower. (good wired connection)
      I think it is a permissions issue.

      tkaiser wrote:

      Also just like any Unix or Linux out there Windows has logging functionality (Event Log -- has been enhanced/fixed wrt SMB connection problems years ago). Why wild guessing when you can have a look what's going on?

      @macom: can you confirm that Event Viewer --> Applications and Services Logs --> Microsoft --> Windows --> SMBClient provides reasonable information with Win10?

      Found the location, but what should I look for?


      geaves wrote:

      Pol de Lepel wrote:

      But after updating the old laptop, it stopped working.
      The update has probably turned off Network Discovery, in File Explorer select Network in the address bar type in \\<ip address of omv> if Network Discovery has been turned off a drop down will appear, select/enable Network Discovery. Your error is related to the most recent cumulative update for 1803, I had the same issue

      I tried to turn it on as asked, but no change. HomeGroup options are not available. Is that a problem?

      geaves wrote:

      With the inclusion of wsdd in omv connections to omv shares should be straight forward, what version of W10? Home, Pro, Enterprise, Education. Also on omv under smb/cifs disable local master browser, this setting has issues with wsdd when wsdd is updated.

      On this laptop it is Windows 10 Enterprise
      And I tried it with enabled and disabled local master browser. Not working
      PS: What is wsdd?

      crashtest wrote:

      Since your MacBook can reach the OMV server, and you mentioned an update to the Windows 10 box:

      The settings in Windows firewall may have been changed, in some way, during the update. You could temporarily turn off the firewall, for a quick test.

      Turned it off, but no change.

      macom wrote:

      tkaiser wrote:

      @macom: can you confirm that Event Viewer --> Applications and Services Logs --> Microsoft --> Windows --> SMBClient provides reasonable information with Win10?
      Might be worth a look.However I have one error listed which is mentioning that my server cannot be reached. For problem solving it is mentioned that this is not a SMB problem (!!!) but probably a network problem or a firewall problem. The server is currently swiched off ;)

      But for sure there is a lot of information provided that might be helpful to track down an issue.

      What should I do with it? Should I turn on the logging? or can I find some useful info here?

      carriba wrote:

      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.

      Well, it didn't work either... :(

      carriba wrote:

      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.

      Yeah I tried it on my father's NAS (ReadyNAS), and had no problems. Can't it be fixed in OMV? How will it be in OMV 5?

      carriba wrote:

      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.

      NFS could be an option, already thought about it as an backup-plan. But I hope I can get SMB working.

      carriba wrote:

      Hope this helps!

      Nope, but thank you ;)
    • New

      geaves wrote:

      Have a look at this this particular setting is specific to W10 Enterprise and Education versions, it might of help
      And what is your advice then? Simply setting up a user/password on OMV or doing something stupid and allowing guest logons?

      As Microsoft explains: 'Since insecure guest logons are unauthenticated, important security features such as SMB Signing and SMB Encryption are disabled. As a result, clients that allow insecure guest logons are vulnerable to a variety of man-in-the-middle attacks that can result in data loss, data corruption, and exposure to malware. Additionally, any data written to a file server using an insecure guest logon is potentially accessible to anyone on the network.'
    • New

      tkaiser wrote:

      And what is your advice then? Simply setting up a user/password on OMV or doing something stupid and allowing guest logons?
      Come on - this is not productive. Let's get the user connected, then worry about security.
      The reason why MS pushed out the guest logon change, for the Enterprise and Education editions only, is that both are usually in AD domains. A workgroup, peer to peer on a small LAN, is another matter.
      ____________________________________________________

      @Pol de Lepel
      With the above in mind, you do have admin access to this Laptop, right? It's not a work laptop, is it?

      First - with OMV's permissions already set wide open, I don't think this is going to help, but it's worth a try:

      Using the same username and password you're using to log onto the Win10 Laptop, setup an identical username and password in OMV, under Access Rights Managment, User (The username and password must be an exact match to the Laptop, cap's and all.).

      Set the Samba share to "Guests allowed". Browseable should be green (on)

      Under, Access Rights Management, Shared Folders, select a folder and click the ACL button. In the Popup you'd want the Group to be Users with at least Read/Write. The rest can be left as is.

      ________________________________

      Also, when accessing the server in Windows Explorer use the server's IP address instead of the name.



      _____________________________________________________________________


      Second - from the Win10 How - To:
      Did you try the Domain Connected Windows 10 Clients and Servers? (You'd need admin access to make this change.)
      Try Level 3 and see what happens.
    • New

      tkaiser wrote:

      And what is your advice then? Simply setting up a user/password on OMV or doing something stupid and allowing guest logons?
      You're very adept at beating people with your virtual whip, you're also very good at picking specific aspects of information to justify your comment found by simply doing a search.

      That specific option is related to Enterprise and Education versions of W10 only it does not require a specific user to be created

      And once again you add a non productive comment to a users thread who is asking for assistance
      Raid is not a backup! Would you go skydiving without a parachute?
    • New

      crashtest wrote:

      Come on - this is not productive. Let's get the user connected, then worry about security.
      Unbelievable. There's a reason that ransomware like WannaCry was that efficient: this sick mentality to not think about security at all and to leave well known security holes wide open or even sabotaging vendor's efforts to strengthen security (this does not apply to users having no clue but to situations where users seek help and then get the advice to weaken security in forums or 'guides' and 'tutorials').

      geaves wrote:

      And once again you add a non productive comment to a users thread who is asking for assistance
      I was asking you why you advice something insane.

      Given these constant tries to keep networks as insecure as possible and even sabotaging Microsoft's efforts to make networking more secure (also applies to the sick recommendation to reenable SMB1) by people like you maybe the only option to solve such problems is to remove any 'guest logons' option from OMV to force users using proper accounts with authentication. @votdev would you accept PRs that try to enforce this policy change?

      One more time Microsoft's explanation what a stupid idea it is to encourage users to use guest logons: 'Since insecure guest logons are unauthenticated, important security features such as SMB Signing and SMB Encryption are disabled. As a result, clients that allow insecure guest logons are vulnerable to a variety of man-in-the-middle attacks that can result in data loss, data corruption, and exposure to malware. Additionally, any data written to a file server using an insecure guest logon is potentially accessible to anyone on the network.'

      'OMV -- malware infections made easy', is this really what you both want?
    • New

      tkaiser wrote:

      Given these constant tries to keep networks as insecure as possible and even sabotaging Microsoft's efforts to make networking more secure (also applies to the sick recommendation to reenable SMB1) by people like you maybe the only option to solve such problems is to remove any 'guest logons' option from OMV to force users using proper accounts with authentication. @votdev would you accept PRs that try to enforce this policy change?
      I'm not sure about this because there is surely HiFi or Media hardware out there that requires accessing SMB shares without credentials. Removing 'Guest login' will cut off this hardware.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • New

      tkaiser wrote:

      'OMV -- malware infections made easy', is this really what you both want?
      Once again you have failed to read and understand, MS quotes in it's technical support site:

      • Windows 10 Enterprise and Windows 10 Education no longer allow a user to connect to a remote share by using guest credentials by default, even if the remote server requests guest credentials.
      • Windows 10 Home and Professional editions are unchanged from their previous default behaviour.
      That setting in W10 Home and Pro is set to 'Not Configured' why, because these are going to be predominantly used in a workgroup environment, on the other hand Enterprise and Education are set to disabled because of their deployment in a domain environment.

      The question should be asked 'why is the OP using Enterprise at home' if this is a work computer and the sys admins have done their job properly that configuration change would not be possible by the end user unless he has local admin access, which again should have been disabled by the sys admins.
      Raid is not a backup! Would you go skydiving without a parachute?
    • New

      votdev wrote:

      because there is surely HiFi or Media hardware out there that requires accessing SMB shares without credentials. Removing 'Guest login' will cut off this hardware
      Fair point. Then nothing can improve since it will be impossible to spread the word how to deal with crappy situations like this.

      Win10 tries authentication with the local Windows logon credentials (the local user's name and password) or the ones added manually in Credential Manager. If this fails then tries guest logon (and most users do not even realize the latter since nobody looks into log files / Event Viewer). The proper solution adding the logon credentials to Windows' Credential Manager and encouraging users to avoid insecure methods/protocols will never work just like encouraging users to rely on names (\\omv.local\share) instead of silly numbers (\\192.168.x.x\share) won't work.

      The post was edited 1 time, last by tkaiser ().

    • New

      Pol de Lepel wrote:

      The ping works fine. Already tested it before
      Unfortunately that's not really helpful since I asked for a couple of different things. Anyway... is ping openmediavault on the Windows box working or not?

      If yes you need an account on the OMV server and then add this account to the Credential Manager (see here for example). Given your OMV account is set up as "user:user1" and "password:pass1" you would open Credentials Manager and then "Add a Windows credential" where you enter the following similar to the screenshot below:

      Internet or network address: openmediavault
      User name: user1
      Password: pass1



      Do things change now? And you really need to make sure OMV is on latest version by using OMV's update tab and installing all available updates.

      Background info: Windows tries to logon to SMB servers with the local user account's credentials first and if this doesn't work does a fallback to the guest account. So you either need to add an OMV user with exactly same logon credentials as your local Windows user or you make use of Credential Manager to store the logon credentials there in a secure way and associated with your OMV server's name.
    • New

      tkaiser wrote:

      crashtest wrote:

      Come on - this is not productive. Let's get the user connected, then worry about security.
      Unbelievable. There's a reason that ransomware like WannaCry was that efficient: this sick mentality to not think about security at all and to leave well known security holes wide open or even sabotaging vendor's efforts to strengthen security (this does not apply to users having no clue but to situations where users seek help and then get the advice to weaken security in forums or 'guides' and 'tutorials').I was asking you why you advice something insane.
      MS has patched the Wanna Cry vulnerability in SMB1, with update 4013389, years ago. It's not the gaping security hole you're claiming it is. Why? As @votdev has already mentioned, there's a lot of hardware out there that requires SMB1. (Scanners, large format printers, etc.) When it comes to a peer to peer LAN at home, or in a small business, there are no hackers waiting, in the middle, to do a "Man in the middle attack". (If someone with malicious intent is inside a SOHO peer to peer LAN, it's already over.) But there's no point in talking about these remote scenarios, with a near vanishing level of probability.

      It's pretty simple, actually. Windows 10 is not going away. In fact, whether we like it or not, Win10 market share will increase over time. If a user can't get into OMV, from a Windows 10, it's already over. Security won't matter - they'll simply move on to something else that "works", regardless of whether it's secure or not. (OR) Perhaps it makes to sense to find out what works, on the way to figuring out what the problem is.

      So why not take it down a notch or two and eliminate the injections of emotion and drama, along with attacks on contributors using words like "stupid", "insane", "sick", etc.? This thread is about getting a user connected to OMV. It's not a place to vent.

      The post was edited 1 time, last by crashtest: edit ().

    • New

      crashtest wrote:

      Perhaps it makes to sense to find out what works, on the way to figuring out what the problem is
      Exactly. So why not starting with this at least one time here so all these wild guesses and trial&error mode can be eliminated in the future?

      Can we agree on guest logons being really bad? Can we agree on that it makes sense to get an idea what's really happening to provide a working advice for users so they can have fun accessing Samba even with Win10 where Microsoft removed the possibility to directly specify logon credentials so now users are either forced to duplicate their local user/pwd onto the Samba server or better use Credential Manager?

      We have an OMV server propagating its services being available at \\OPENMEDIAVAULT. If this doesn't work the next logical step is to check for potential name resolution issues and once this is resolved then see whether/why authentication fails. Always with the bigger goal in mind to avoid insecure setups and especially not to encourage users weakening default security settings of their machines.
    • New

      RE the above - TL:DR:

      I'll ask you one simple question - do you own a Windows 10 PC? If you don't, enough has been said.
      You're reading things on the internet and expressing an opinion on subjects, without experience or context.

      If you don't "get it", and don't know how to work with beginners and forum contributors, without getting overly excited and injecting emotion into it, further discourse is pointless.

      The post was edited 1 time, last by crashtest: edit ().