Mint 19 Samba shares 'Access is denied' from Windows 10 (works in Mint 18) [SOLVED]

[msummerfield]

I am having trouble accessing Samba shares on Mint 19.1 from my Windows 10 (Home) laptop. I have read the guide at Mint 19 and Samba File Sharing Changes, but it does not seem to address my problem.

I have winbind and NSS working happily on the Mint server, successfully resolving all names on my network. All relevant hosts are currently assigned fixed IP addresses, and listed in both hosts and lmhosts files on the Windows machine. As we shall see, name resolution is not a problem. With various different Samba configurations, the Mint server and Windows laptop are happily talking to each other. The problem i am having seems to be with authentication.

In Mint 19, I installed Samba (4.7.6) and started with essentially the same smb.conf as I have been using in Mint 18 (Samba 4.3.11). This is currently still working with Mint 18 and the Windows 10 laptop without any issues. It is basically a default configuration, with the following initial share:

Code: Select all

[msummerfield]
        path = /home/msummerfield
        writeable = yes
        browseable = yes
        guest ok = no
        valid users = msummerfield
        create mask = 0644
        directory mask = 0755

Initially, I have not created any SMB users (i.e. the SMB password db is empty). At this point I can see the server from Windows, including the available share (i.e. 'msummerfield'), but of course I cannot access it, because the required SMB user does not exist. I have increased the log levels (log level = 3 passdb:10 auth:10 winbind:10) in order to observe what is going on. Attempting to access the share, unsurprisingly, results in:

Code: Select all

[2019/01/01 14:48:50.193714,  2] ../source3/smbd/service.c:338(create_connection_session_info)
  guest user (from session setup) not permitted to access this share (msummerfield)
[2019/01/01 14:48:50.193745,  1] ../source3/smbd/service.c:521(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_ACCESS_DENIED
[2019/01/01 14:48:50.193799,  3] ../source3/smbd/smb2_server.c:3139(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_tcon.c:135

So then I create the SMB user (sudo smbpasswd -a msummerfield).

Now it is impossible to browse the server and/or to see or mount the share. On Windows, I get a dialog saying 'Access is denied', and requesting me to enter a password. This just keeps repeating, i.e. I never receive a final red-cross 'not accessible' dialog, unless I enter an incorrect password (i.e. it looks as though the Samba server is recognising a correct password, but then denying access to the authenticated user). Log says:

Code: Select all

[2019/01/01 14:53:41.049984,  1] ../source3/smbd/smb2_tcon.c:227(smbd_smb2_tree_connect)
  smbd_smb2_tree_connect: reject request to share [IPC$] as 'SERVER\msummerfield' without encryption or signing. Disconnecting.
[2019/01/01 14:53:41.050034,  3] ../source3/smbd/smb2_server.c:3139(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_tcon.c:135

OK, so let's enforce encryption and signing, i.e. add the following to smb.conf:

Code: Select all

        server signing = mandatory
        smb encrypt = mandatory

The result is the same on the Windows side - access denied. On the server side, the encryption/signing rejection disappears, but access is still denied:

Code: Select all

[2019/01/01 14:55:44.667593,  3] ../source3/smbd/smb2_server.c:3139(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_server.c:2366

Incidentally, if I set up a guest share, and delete all SMB users from the db, then I can browse and access files from the share. (I cannot write to the share in this configuration, but I have not really attempted to set that up properly - I was just trying to ensure that it is possible to see and access a Samba share in some form). Of course, guest access is not what I want. I need particular users to have read/write access to selected shares.

I have tried all sorts of other things, fairly randomly really, but the above are the only ones that make any logical sense, and have any impact on what happens and what appears in the log files.

In summary: the Win10 client and Mint server are communicating. The client can access shares and individual files in some configurations (e.g. the 'guest only' setup). But as soon as I try to access the server using an actual SMB user account, access is denied.

This has me tearing my hair out. As I say, it all worked - and still works - perfectly in Mint 18. Any assistance would be greatly appreciated.

[altair4]

I'm telling you upfront: I don't know. I don't know because I can't reproduce it.

Given the quality of your original post you most likely went through all this yourself but:

[1] Did you ever create the share from your file manager? If so what is the output of this command:

Code: Select all

net usershare info --long

If you have a share defined in usershare and one in smb.conf itself - of the same folder - samba may be confused.

[2] Did you verify that msummerfield is actually in the password database?

Code: Select all

sudo pdbedit -L

[3] Does testparm show any errors or warnings?

Code: Select all

testparm -s

[Capecutterman]

Welcome to the Club!

Been running nicely on 18.3 Sylvia - able to talk to the Win 10 machine, the MacMini and the Netgear NASes - no problems.
Like a fool I installed 9.1 Tessa over the top of Sylvia and now have all sorts of problems.
Autologon for some obscure reason disables NetBIOS (and yes Virginia, there are still people who use it)
A sort of Samba get installed that seems to be more of a backend for avahi and is missing a lot of the old Global settings and various chunks of the full Samba.

Wipe drive, full install 19.1, update and do all the right things - still more problems, rinse and repeat.

Thank you VERY much Mint-people!

It is suggested that enabling the (quite rightly deprecated) insecure SMB1 protocol on the Win10 box will cure it but I'm darned if I'm going to do that.

Have gone back to 18.3 Sylvia and tinkering with Samba to get it working again - forgot all my old settings, not that complex but a bore).
[Why setting up Samba still has to be such a try-it-and-see, boot, reboot, tinker and twibble business in 2019 I have no idea]

Cinnamon 9.1 looks gorgeous but the networking is totally screwed up - avahi is NOT reliable and "Samba" has been messed up.

Wasted a lot of time on this now and likely to waste even more before I'm right again.

The Cutter (longtime Mint supporter - might have to go back to (ugh!) Ubuntu again.

[msummerfield]

Thanks @altair4. I have read many of your posts and replies in trying to figure this out, so I know that you are the expert and suspect that if you are stumped I may be SOL!

I had tried [2] and [3], but not [1]. I have just given that a go (calling the share 'homedir'), and the output of net usershare info --long is:

Code: Select all

[homedir]
path=/home/msummerfield
comment=msummerfield home
usershare_acl=Everyone:R,server\msummerfield:F,
guest_ok=n

Attempting to access this from Win10 (either by browsing, or explicitly adding \\server\homedir) produces exactly the same results as defining the share in smb.conf. No big surprise there, I guess.

Another point to note is that the shares can successfully be accessed and mounted from the Mint 18 box (i.e. the one that is accessible from Windows 10), i.e. the following works as expected:

Code: Select all

$ sudo mkdir /mnt/mint19
$ sudo mount -t cifs -o credentials=/home/msummerfield/.config/smbcredentials,iocharset=utf8,uid=1000,gid=1000 //server/msummerfield /mnt/mint19

I also have an old PC running Windows Vista which exhibits exactly the same behaviour as Windows 10, with both the Mint 18 (works) and Mint 19 (doesn't work) boxes. So this is not a Windows 10 specific issue, it is an issue with some aspect of the default configuration of Samba 4.7.6 on Mint 19.1.

I now have a clone of the Mint 18 setup running in a VirtualBox VM on the Mint 19 box. As a workaround, I could use the VirtualBox file sharing to mount the host filesystems on the VM, and then share them from there. I would then be running an entire VM just as a Samba file server. This would not actually be a huge deal (the machine has a quad-core Intel Core i7-7700K CPU and 64GB of RAM), but is nonetheless a bit insane!

[msummerfield]

Hi @Capecutterman,

Thanks for your reply. At least I know I am not alone!

You needn't worry about the option of enabling SMB1 on the Windows box. I already tried setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel to 5, and it did not help, although it did allow me to waste further time trying a number of SMB1-based configurations on the Linux box!

[altair4]

At the moment the only way I can reproduce the error is to use a username map in smb.conf containing the wrong mapping. In my case I mapped a client user to a non-existent server user.

When I do a cifs mount I get a Permission denied error on the Linux client. As soon as I fix it the mount is successful.

I'll keep poking my test box with a stick to see how else I can get an error.

[msummerfield]

Thanks for trying, @altair4, although I am not sure that there is much to be gained from testing with a Linux client. I have had no difficulty accessing the shares from the Linux Mint 18 client, even while trying a range of different configurations in efforts to get the Windows clients to work.

I am not using a username map (my client and server user names are the same), although I did try adding an explicit mapping at one stage, which (unsurprisingly) made no difference at all.

[altair4]

The only thing I can offer at this point is to tell you what I would do if I were in your situation. I'm not convinced yet that the problem is with the Linux end of this so I would try some experiments.

[1] Run Mint in a live session.

Boot into the install medium not to reinstall but to run in a Live session. Then:

** Update apt: sudo apt update
** Install samba: sudo apt install samba
** Create a usershare of the Public folder at /home/mint/Public.

Do not create a guest share first. Create the share to not allow guests. And don't create a share of the entire home folder just the Public folder.

** Create a samba password for the user mint: sudo smbpasswd -a mint

Then access the share explicitly in Win10 using its mDNS name: \\mint.local\public You should see this:

Win10-MintLive.png

[2] Access your regular install from Win10 as though that install was a different machine.

There are 3 ways ( actually 4 ) that Win10 can access Linux: By ip address, mDNS name, and netbios name. Windows sees each one as a different machine even though they all resolve to the same one - go figure. Don't use the netbios name since that is the one you use when browsing for the share. Ask for it explicitly in explorer by either its ip address \\192.168.0.100\msummerfield or mDNS name \\hostname.local\msummerfield


[3] EDIT: Just thought of one other thing you can do on the Win10 side: Map the share - but using the as another user option.

Windows doesn't understand the concept of accessing a server's shares with different credentials through explorer but it does in the mapping process. When you create the map you are offered the option to Connect using different credentials

At first, pass it the Samba user name and password ( I'm playing a hunch here ) and if that doesn't work create a new user on the Linux machine and give it its own samba password then use that to map the share making sure to add that user to the valid users list.

[msummerfield]

@altair4, you are a legend! Your number [2] suggestion did the trick. By using the mDNS name I am able to add the server itself and/or the individual shares as a network location, map the shares as network drives, and access the individual shares directly.

I am going to mark this as [SOLVED] for the benefit of others who may come here with the same problem. Of course, there is some underlying problem with accessing the server using the netbios name which this works-around rather than solving, but that is now secondary to my main goal of accessing the shares from Windows.