[SOLVED] Mint 19 Network SAMBA shares not showing File Manager

[jadeopia]

Regardless of where the precise fault lies, Samba to Mint 19 is terrible. Whatever Samba did or didn't do, it still works easily with Mint 18, so part of the blame at rests with the Mint team and Mint 19.x.

Mint has had samba built in by default for years, yet it isnt now.. why??????? Lot's of things are a princess in mint 19... they need to up their game

[altair4]

More of an FYI but this whole inability of the file manager to scan the network for NetBIOS hosts is fixed in Ubuntu 19.04 Beta. A change was made to gnome's gvfsd-smb-browse utility to make it work like smbtree does in the command line. Will it still work when 19.04 is finally released? Don't know.

It doesn't do any good for Mint users or anyone like myself that uses Xubuntu 18.04 but that's the way Desktop Linux works with updated software.

[SaintDanBert]

...
Then rebooted to the installed Mint 19 (where networking/printer detection did not work) and replaced the /etc/samba/smb.conf with the version copied from the Linux mint 18.3. I then rebooted the system.
...

Would you please 'diff' the two copies of smb.conf so that we can see what changed between the default from Mint 18.3 and from Mint 19.X?

Thanks in advance,
~~~ 0;-Dan

[altair4]

It won't be in smb.conf. It's in the default settings for samba. Those are two different things.

Mint 18 uses version 4.3.X of samba so the setting there is:

testparm -sv /dev/null | grep "client max protocol"
...
client max protocol = default

Mint 19 uses 4.7.X of samba and the default setting there is: ... well it's the same thing: default.

It's only when you use the man pages you see what is done:

In Mint18: The value default refers to NT1.
In Mint19: The value default refers to SMB3_11

Anyhoo, the real problem is not smb.conf or the default settings it's gvfsd-smb-browse and Ubuntu thinks it's fixed.

[Huecuva]

How did I not see this thread when I was looking? Man, can we get that post about the Mint 19 Samba and network changes stickied maybe? it's very handy.

[omelette]

A big Thank You to crustycurmudgeon for pointing to a workaround for this bug - which was bugging the hell out of me! I'm referring to the inclusion of the 'client max protocol = NT1' line in smb.conf, which fixed networking for me as well.

[sdet00]

For what it is worth, forcing SMB browsing to SMB 1.0 does not work for me. I still cannot browse the "Windows Network". That said, all my workstations are on the latest version of Windows 10, with SMB V1 disabled. Typing in smb://srv1 works though.

[altair4]

For what it is worth, forcing SMB browsing to SMB 1.0 does not work for me.

Actually, setting the client to NT1 is no longer required in Mint19 because Ubuntu made that automatic for host discovery with an update:
https://bugs.launchpad.net/ubuntu/+sour ... mments=all

Regrettably, they didn't do it correctly which resulted in another bug: https://bugs.launchpad.net/gvfs/+bug/1828107

The latest bug would affect Win10 or any other SMB / Samba server that disabled SMBv1 on the server side.

All of this concerns host discovery not host connection. You can still connect to the server explicitly by ip address, netbios name ( if enabled ), and by mDNS host name.

[tictactux]

before you go through reboot orgies, try to edit $HOME/.smb/smb.conf and add just the bare necessities:

Code: Select all

[global]
  client max protocol = SMB3_10
  client min protocol = SMB2

For some funny reason, the gvfs subsystem (running in userspace) seems to prefer the user's smb.conf over the system's smb.conf. I could reproduce this behaviour on several 19.1 machines.

[altair4]

try to edit $HOME/.smb/smb.conf

There is no such file at that location.

The client protocol series is a negotiated process and the max is by default already set at SMB3_11 but I'm just being picky now.

[tictactux]

SMB3_11 fails with NetApp appliances while SMB3_10 works fine. I was pulling up my own example which shows that NT1 is not a good workaround.

And no, the .smb folder does not exist by default, it must be manually created.

[jontrv]

Is NT1 a good idea?
In the Windows 10 world, NT1 has been disabled because of a serious bug in the protocol itself,
http://cve.mitre.org/cgi-bin/cvename.cg ... -2017-7494
which M$ choose to bypass by disabling the NT1 protocol.
Does Linux (Mint 19.1) (with later kernels) have a good defence against this bug? Is the SMB protocol driver even in the kernel?
Like many others, I may have no option but to fallback to NT1, as my NAS will almost certainly not have support for newer protocols.
Before anyone prompts me, I have already made sure port 445 is not exposed to the public internet.
JT:

[altair4]

Is NT1 a good idea?
In the Windows 10 world, NT1 has been disabled because of a serious bug in the protocol itself,
http://cve.mitre.org/cgi-bin/cvename.cg ... -2017-7494
which M$ choose to bypass by disabling the NT1 protocol.
Does Linux (Mint 19.1) (with later kernels) have a good defence against this bug? Is the SMB protocol driver even in the kernel?
Like many others, I may have no option but to fallback to NT1, as my NAS will almost certainly not have support for newer protocols.
Before anyone prompts me, I have already made sure port 445 is not exposed to the public internet.
JT:

First:

Actually, setting the client to NT1 is no longer required in Mint19 because Ubuntu made that automatic for host discovery with an update:
https://bugs.launchpad.net/ubuntu/+sour ... mments=all

Regrettably, they didn't do it correctly which resulted in another bug: https://bugs.launchpad.net/gvfs/+bug/1828107

The latest bug would affect Win10 or any other SMB / Samba server that disabled SMBv1 on the server side.

All of this concerns host discovery not host connection. You can still connect to the server explicitly by ip address, netbios name ( if enabled ), and by mDNS host name.

And by accessing the server explicitly the linux client will connect with whatever smb dialect the server requires.

Second: As for Win10 in particular there are any number of possible remedies: Windows 10 and Samba File Sharing : viewtopic.php?f=42&t=199907

EDIT: Missed your reference to the kernel:

Third: THe linux kernel doesn't control smbclient which is what the file manager uses to discover and connect to hosts. It does however control CIFS and there the default connection is made with SMBv3 You can always set the smb dialect to an earlier version by specifying that in your cifs mount expression with a vers=1.0 or vers=2.1 for example. So yes, the Linux kernel can accommodate those servers still using SMBv1

[pharmankur]

I am having exactly the same problem.
I am using LM 19.1
Default File Manager - Nemo
Any windows share samba location opens up very well for the first time. Once we unmount that location and try to mount it again , it weirdly informs that "the location is not found". When I restart computer, again it works well for 1st time.
In my smb.conf I have already added

client max protocol = NT1

But it does make NO difference.


I did not get any solution, But did get a work around. (Use other file manager than Nemo)
Install Thunar and/or Dolphin

Code: Select all

sudo apt-get install thunar dolphin

Open the shared location from Thunar -- It works well !
Now try to open shared location from Nemo again --- It WORKS WELL !!!