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

[A_J_Jackson]

2 problems, probably related. New install of Mint 19. Samba installed. Trying to connect to office Windows network (simple workgroup sharing). In terminal smbtree shows the full expected network shares. They do not show in either file browser or printer set up - trying to connect to a network (windows) shared printer; I have tried both the graphical printer set up and CUPS browser interface. I can connect to a printer directly networked but not a shared printer on a Windows machine (that I could connect to with LM 18). I have never had trouble with previous versions of Mint. The shares I have set up on my computer (Mint 19) are accessible through other computers on the network. TX for any assistance.

[altair4]

Can't comment on the Printer issue but there have been changes in samba since Mint18.

Long version: Mint 19 and Samba File Sharing Changes

Short version:

Edit /etc/samba/smb.conf and right under the workgroup = WORKGROUP line add this one:

Code: Select all

client max protocol = NT1

Then reboot.

If you have Win10 on your network and it has disabled SMB1 on the server side you will not be able to connect to it.

[A_J_Jackson]

adding
client max protocol = NT1 to conf file did not help.

If I have workgroup=WORKGROUP (in conf)
then in file manager I see a WORGROUP folder with only my own computer shares.
If I have workgroup= XYZ (name of office workgroup) then it is back to blank screen
in the Windows Shares folder of the file manager.
I did a full reboot after each alteration to samba.conf

[altair4]

Assuming this is a regular old workgroup thing we are talking about it would be best to go through the checklist: viewtopic.php?f=42&t=88146&start=0

[altair4]

I've decided all on my own to post your response here for consistency sake:

Yes, have followed that. Why does the full tree of samba shares display in the terminal with command smbtree but I can't access them in file manager or printer set up? It has only happened with Mint 19, prior versions have always been file. None of the network machines are running Win10, only XP to Win 7, plus 1 that is Mint 18. The shares on the (new) Mint 19 are accessible to the machine with Mint 18 - directly in Network connections without opening 'Windows Network'. The Mint 19 shares also show on the Mint 18 'Windows Network/XXGROUP folder. So my Mint 19 is sharing to the outside network but no applications on Mint 19 can see the outside network. Firewall on Mint 19 is disabled. Remember that smbtree does display, accurately, the network shares.

Thank you

You write as though you think Desktop Linux is the result of an integrated development process where all of the parts are owned and accountable to one master. It is not.

smbtree is owned by Samba and they fixed smbtree by having it drop down to SMB1 ( NT1 ) to do its scan of the network. Network browsing in the file manager is done by gvfsd-smb-browse which is owned by Gnome. I doubt they even talk to each other.

Samba sharing in an all Linux network or one with macOS involved is a whole other situation. Network browsing there works by default because it doesn't use any of the old Windows netbios process. It uses avahi.

Since Mint to Mint works it's not a samba file sharing problem it is a netbios name resolution problem. Have you tried to access the share on Windows by it's ip address?

[A_J_Jackson]

Finally have all working. On a whim I started computer with a live boot version of Mint 18.3. All networking, printer detection worked so I copied the smb.conf file from its /etc/samba folder. 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. Upon reboot network printer detection worked but file manager browsing did not. I then added the line

client max protocol = NT1
after
WORKGROUP=WORKGROUP

rebooted the system again and everything worked, including file manager browsing.

[Gaugamela]

Finally have all working. On a whim I started computer with a live boot version of Mint 18.3. All networking, printer detection worked so I copied the smb.conf file from its /etc/samba folder. 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. Upon reboot network printer detection worked but file manager browsing did not. I then added the line

client max protocol = NT1
after
WORKGROUP=WORKGROUP

rebooted the system again and everything worked, including file manager browsing.

I did this same thing and it also worked.
However, when I try to specificy a specific samba location (my workplace samba share, which is password protected) I cannot connect to it. The same goes for printers. It says that user is denied and does not recognize my username.

[GlammaGeek]

I registered just to say THANKS because this also worked for me. I was on the verge of asking for help but I'm the kind of girl who likes to try and figure it out on her own. That's how I came across this solution.

I'm running 18.3, XFCE but my issue was exactly the same. Meaning that I could connect to network shares if I entered the IP address, but I could not browse the workgroup in my file manager (Thunar). I got a new computer so I'd renamed the original smb.conf to old-smb.conf and copied the smb.conf from the old rig.

Nothing worked for browsing the workgroup until I renamed the original version from old-smb.conf back to smb.conf. Then, I renamed the copied file from smb.conf to old_smb.conf. I also entered my correct workgroup name, then copied and pasted the share information from the bottom of the smb.conf file from the old rig. After rebooting, everything worked!!! YAY!!!

For the record, before I restored the original smb.conf, no results would show up when I ran smbtree in the terminal. After restoring the original file and including the above-mentioned info from the old, smbtreee worked like a charm!

I'm super happy. Now that I've finally registered, I'll try not to be a stranger...LOL Thanks much for helping a poor GI down on her luck.

[Gaugamela]

Well, the samba shares at my work disappeared again today.

[pratikmahamuni]

It worked for me also.
Thanks a lot

[Polymorph]

@A_J_Jackson

This worked for me too.

Thanks

[mb7]

Can somebody explane me, why nobody fix this?
Why is samba drop in LM19?

[altair4]

Why is samba drop in LM19?

I explained the "why" in my HowTo:

Samba changed the maximum client smb dialect that it can use from SMB1 to SMB3 so that it could connect to servers that have disabled SMB1 like Win10. This inadvertently disables netbios host discovery so if you go to Network > Windows Network you will see something like Folder is Empty in Ubuntu and just a blank screen in Cinnamon, Xubuntu, etc,..

You can restore it's discovery ability by editing /etc/samba/smb.conf and right under the workgroup = WORKGROUP line add this one:

Code: Select all

client max protocol = NT1

And then reboot. Yes, reboot.

But: If you set the max back to NT1 you will be able to see a server that has disabled SMB1 ( Win10 ) but you will not be able to access it through the file manager.

Can somebody explane me, why nobody fix this?

That is a more complex question. It's not going to be Mint or Ubuntu or even Debian that fixes this because they know nothing about samba. I think - at it is admittedly a guess on my part - that the culprit is gvfsd-smb-browse. Gnome owns that and they have yet to understand the nature of the problem, why it matters that it should be fixed, or their responsibility in fixing it.

[mb7]

What I mean is... How it works without any issue on Mint 17 and 18 but not on 19?

[Polymorph]

I agree.
I have not had any problems until LM 19. Linux is becoming more and more popular and should work OTB. The OS has been around for a long time now and we should be past having to edit smb.config like we used to 10 years ago.

[catweazel]

I agree.
I have not had any problems until LM 19.

I don't agree. You seem to not understand how the linux ecosystem works. It has absolutely nothing to do with Mint, it's what is called an upstream problem. That means a team that provides support and maintenance for an application is further up the chain in the ecosystem. Besides, these kinds of issues are easily rectified by doing a simple search or by actually reading the words written above by @altair4.

Linux is becoming more and more popular and should work OTB. The OS has been around for a long time now and we should be past having to edit smb.config like we used to 10 years ago.

And Windwoes should be past having a registry. Right. I can see that happening... never.

[crustycurmudgeon]

Just thought I'd muddy the waters here a bit more; Several weeks ago, soon after stable release, I ran the Mint 18.3 => Mint 19 upgrade process and it was absolutely flawless. I was SO psyched, until I found that no workgroup pc's or showed up in the file manager... My local lan is mixed Mac/Windows/Linux with two shared storage servers.

I posted a query at Nemo cannot see network computers after Mint 19 upgrade and was referred to the samba post at Mint 19 and Samba File Sharing Changes. Finally, I also reviewed the HowTo: Samba Browsing Problems Checklist just to be sure.

As noted in my post, I did enable the changes as instructed in Mint 19 and Samba File Sharing Changes, but these had NO EFFECT on the new Mint 19 upgrade. I also tried copying the smb.conf file from my working Mint 18.3 system backup, but still no joy, so I restored my system backup and went on with Mint 18.3.

Several weeks later, I decided to take the plunge again and see if I couldn't get things working. I ran the upgrade installation and after the final reboot, I hesitantly opened Nemo and was pleasantly surprised to find that I can see and browse all my LAN workgroup shares without difficulty.

What was different?

After taking a deeper look, I saw that my previous change to the smb.conf file had been left after returing to Mint 18.3, so the additional switch to restrict to NT1 was already in place when I did the upgrade. I can't explain why, but I am convinced that having the smb.conf already configured with "client max protocol = NT1" BEFORE the upgrade was the key. I absolutely know that I did everything correct with the first upgrade and the changes I made to the smb.conf file after upgrading made did not resolve my inability to browse and see workgroup systems and shares (yes, I rebooted).

FWIW, and considering the confusion and large number of posts about this issue here, I think it's probably a good idea to recommend that the changes to the smb.conf be made BEFORE the upgrade. It's clear that some configurations are finding that doing it after doesn't work.

[rudiklein]

YESSS! The NT1 did the trick!

Edit /etc/samba/smb.conf and right under the workgroup = WORKGROUP line add this one:

Code: Select all

client max protocol = NT1

Then reboot.

[LMDE2Fan1]

Here's the Ubuntu bug: https://bugs.launchpad.net/ubuntu/+sour ... ug/1778322

Looks like Ubuntu has a fix that has been released and we should all have it by now BUT, the very last comment in the bug says that the Ubuntu fix isn't working and won't work until they get the Samba change. Sounds like Samba needs to fix something on their side.

[PNH]

I get sick of how unhelpful some people on this forum are. If you don't want to help, that's fine. But the "help" that begins or resorts to "you don't seem to understand how Linux works" with a decidedly "put down tone" are the opposite of help. A lot of people come from Windows to Mint because it is supposed to be the easy, friendly route. 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.

Those of you that know or think you know how it all works, either be genuinely helpful and polite, or don't clutter up the forum with your kind of "help" or theats to others that they will be kicked off because they express common frustration of those trying to solve a problem.