Windows shares / samba Trouble shooting


  • THANK YOU,


    I did a new install, and had the exact same problem. Spent countless hours scouring forums and troubleshooting. I was about to give up, then i read your post, and 10 minutes later everything was working OOB!!

  • Hello,


    I'm having troubles with the SMB performance on OSX Sierra.
    It turned out it is a general issue if signing is enabled on the samba server.
    On the OMV (3.0.99) I was setting some extra options to speed up the connections.

    Code
    client ipc signing = default
    server signing = disabled
    min receivefile size = 16384
    read cache size = 524288
    write cache size = 524288
    getwd cache = yes
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    client min protocol = SMB3


    These option are also visible if I check the /etc/samba/smb.conf




    However If I mount the share on my Mac those options seems not to be effective:




    Signing is on, SMB 1-2 are still supported :(


    I did restart both NAS and Mac.

  • Got a similar error while enabling the SMB Share via the UI..

    It said Hostname needs to be <15 Character.


    Enabled it from Shell

    `systemctl start smbd` and the share worked without any hitches


    Where do you configure the hostname via the webUI?

  • Helo ! I just found out that sometimes (always ?) NetBIOS is not activated by default in Win10.


    I found a solution here : https://answers.microsoft.com/…93-4a4b-bfb3-935fa17e9a2b

    To solve the pb :

    1. Win+X -> Control Panel->Network and Sharing Center->Change Adapter Settings
    2. Right click on the Network Adapter->Properties
    3. Click to select Internet Protocol Version 4 (TCP/IPv4) -> Properties ->Advanced->WINS
    4. Click to select "Enable NetBIOS over TCP/IP" then click OK.
  • Microsoft has totally busted SMB/CIFS. I have tried every conceivable combination from everywhere on this forum or the web and SMB is DOA!

    Which means OMV is useless on a Windows network.


    What can the OMV developers do to fix this?


    Or is there another option, like, NFS?


    I am not a newbie but this one has me stumped.


    One other tidbit: I have an old ThinkPad that is running Win 10 Pro V 1909 and it works perfectly.

    This just should be this hard.

    kaosken (and, yes, it is pronounced chaos)

    • Offizieller Beitrag

    I have tried every conceivable combination from everywhere on this forum or the web and SMB is DOA!

    Which means OMV is useless on a Windows network.

    Not true. I'm running fully up-to-date W10 clients without issues. On the other hand, OEM's attempting to help PC users, may have changed various settings and security policies in your Win10 installation.


    Have you looked here -> Connect W10

  • macom

    Hat das Label OMV 3.x entfernt.
  • Hi crashtest

    Thanks for putting the great Connect to OMV with Windows 10 guide together.


    I recently had to rebuild a Windows 11 laptop after the boot drive got messed up.


    So, I followed your guide - and recognised several of the steps I had tried in previous attempts to get this laptop and others to connect to OMB Samba shares - so it was great to see them all in one place - thanks.


    However, despite going to every possible step in your Connect W10 document, I still could not get this laptop to connect.


    My RPI server appeared under Network just fine, but when tried to

    • click on it
    • tried typing in the IP address in the address bar
    • adding a Network Location under This PC and specify RPI or the IP address:

    I would just get the following Windows Popup error - I could not even see the samba shares. On previous computers, I could see the shares, but when I then tried to click on the shares, I would get issue - but here I could not even get as far as seeing the shares.


    Network Error

    Windows cannot access \\192.168.2.28 (or RPI etc)

    Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.

    Error code: 0x80004005

    Unspecified error


    Off course Diagnose did nothing useful.


    In the end, out of sheer desperation, I just thought I would check the Windows Credential manager - because I know I had previously had issues on another PC with saved credentials for the same IP address - even though this was complete re-install of Win 11!!


    As you may know the Credential manager can be run by executing

    rundll32.exe keymgr.dll, KRShowKeyMgr 

    in the Run dialog or command prompt etc

    I confirmed there were no stored credentials (as you would expect) and then decided to manually add some credentials here for the RPI



    Clicked OK, and Close - went back to File Explorer and hey presto RPI was now fully browsable and accessible. Hurrah!!


    Just to be Clear - I do NOT recommend using the pi username here - its just for demo purposes. This should also work with other user accounts you have created on OMV.


    Perhaps you could consider adding the above to the guide - in case it helps others?

    The above Credential manager is also useful for deleting stored credentials - an issue I had on a different PC, when I initially connected to my RPI using a username with read-only samba privileges and I still could not get write-access even when I tried to connect again user a fully permissioned user name!. Once I deleted the read-only credentials from the Credential store, I was then able to access using the other username.

    2 Mal editiert, zuletzt von harry66 () aus folgendem Grund: added clarification about PI username.

    • Offizieller Beitrag

    First, I'm glad you worked out the connection issue. The short guide you looked at was the first step, to make a Client - Server connections possible within a LAN.

    The second step is permissions and access control. For new users, I addressed this topic -> here with Linux permissions that are wide open. That gets new users started but, -> by my own admission (in para 1), wide open network shares should be tightened up.

    Access control or, in the Linux World, file and folder permissions is another topic.

    Using Windows Credentials, along with a preexisting server user account (in your case the pi user), is one way to to grant permissions to a restricted server share. It is, however, a bit dangerous to suggest to new users. R-PI installations have a preexisting user account (pi). Other installations do not. For amd64, and Armbian installs, using Windows Credentials for access might encourage the user to use preexisting accounts like admin or root. This would create a considerable server security risk.

    If you want more granular access control, take a look at this doc -> Getting Started with NAS Permissions in OMV . It will show you how to set up permissions that allow users to gain access specified server shares, using their Windows user account. Try it and tell me what you think.

  • Hi crashtest


    thanks for the reply.


    I fully agree about the dangers of using the pi username. That was just for demo/screenshot purposes.


    I actually used a a personal user name which I had created in OMV previously - I have created different usernames for various family members as per then need to access the various samba shares.


    The point of my post was how entering the username and password into Credentials manager was the only way to see the shares under RPI in Windows or map a folder to any of them etc. This was very weird - because I did not have to do this on other PCs in the home - a mixture of Win10 and Win11 devices.


    Also - thanks once again for the great work on the forum and OMV. Allowed me to replace a power hunger and noisy QNAP with an RPI+SSD - low powered silent bliss..

    • Offizieller Beitrag

    Credentials manager was the only way to see the shares under RPI in Windows or map a folder to any of them etc. This was very weird - because I did not have to do this on other PCs in the home - a mixture of Win10 and Win11 devices.

    That is weird. In the vast majority of cases, when permissions are employed, a user can "see" an SMB share under Network, but they can't open it. These are the odd issues that I can't explain regarding Windows, but I believe they may have something to do with "Microsoft Partners" (OEM's) setting values in the registry that affect security and access control. (They're trying to "help" users.)
    __________________________________________________________________

    When you reinstalled on the client with the access issue:
    Did you use a retail Windows disk, or was it an OEM recovery disk or perhaps a recovery partition on the hard drive?

    Windows 11.... Man... Windows 10 was suppose to be the last one, a rolling release. Windows 11 wasn't even supposed to happen. M$'s constant flux with their flavors of OS is wearing me out.

    • Offizieller Beitrag

    Sorry. I know nothing useful about Windows 11 and have nothing to offer on why the Win11 client is behaving as it is.

    Still, unless M$ is completely revamping how access control works, duplicating Windows usernames and passwords on a Linux server should allow access from a Win11 client. At this point in time, Win11 would almost have to be backward compatible.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!