SAMBA share issue I've not been able to solve.

[charlesmouse]

Hello all, I'd appreciate your help with a networking issue I'm having - no doubt a common enough question. Sorry for bringing up the subject yet again, but after some 'googling' and searching of the forum I couldn't track down the issue holding me back:

Linux Mint 21.3 Virginia, fully updated.
Currently running as a VM + VMWaretools under VMWare Workstation Player 17 with a bridged network connection on a heavily stripped-out copy of Windows 11 - I'm on my semi-annual testing phase to see if there's a Linux I can live with as a daily driver, having been attempting to abandon Windows since the post-XP days...
...My 'fileserver' is a Debian-based ESXi VM specifically running DietPi and CasaOS using SAMBA for sharing - all is good, and it's open guest shares are fully accessible by every other computer on the network, Windows, other DietPi-based VM's, a selection of retro-OS's, and a MacOS VM. I did have a little fun with SAMBA network share discovery from Windows, but that was fixed with a script on the server.

Network Server SAMBA config:

Code: Select all

[global]
## Browsing/Identification ###
   workgroup = LAN
## fruit settings
   min protocol = SMB2
   ea support = yes
## vfs objects = fruit streams_xattr
   fruit:metadata = stream
   fruit:model = Macmini
   fruit:veto_appledouble = no
   fruit:posix_rename = yes
   fruit:zero_file_id = yes
   fruit:wipe_intentionally_left_blank_rfork = yes
   fruit:delete_empty_adfiles = yes
   map to guest = bad user
## hosts allow = 192.168.0.0/16
## hosts deny = 0.0.0.0/0
   include=/etc/samba/smb.casa.conf

Network Server SAMBA Shares:

Code: Select all

[Audio]
comment = CasaOS share Audio
public = Yes
path = /media/Store/Audio
browseable = Yes
read only = No
guest ok = Yes
create mask = 0777
directory mask = 0777
force user = root

[Config]
comment = CasaOS share Config
public = Yes
path = /media/Store/Config
browseable = Yes
read only = No
guest ok = Yes
create mask = 0777
directory mask = 0777
force user = root

...you get the general idea.

All is good and I've had no issues at all with this set up... on to my MINT test install...

Not knowing if MINT comes with SAMBA / CIFS as standard I did a "sudo apt install" for both after I fully updated the system. As a networking test I added the following to MInt's /etc/samba/smb.conf:

Code: Select all

...

workgroup = LAN
...

map to guest = bad user
...

hosts allow = 192.168.0.0/16
hosts deny = 0.0.0.0/0

[mintshare]
comment = Open Linux Share
path = /home/charles/linuxshare
read only = no
guest ok = yes
force create mode = 0755
force user = charles
force group = charles

...where "..." represents the parts of the default smb.conf file I left unaltered.

As hoped this works perfectly with a discoverable public 'mintshare' in my 'LAN' NETBIOS group that is fully readable and writable, and requires no password for access - so far so good.

Now here's where things go a bit runny...
What about accessing my known properly functioning SAMBA shares on my server VM from my test Mint VM..? Here's a couple of screen shots illustrating:

1) What Mint can find - good enough!

...but for some reason it wants me to enter a password for a public share that doesn't have a password!

2) The error I get.

...regardless of what I enter in to the dialogue - even the root login details for the SAMBA server!

So...
What's going on?
-Why is Mint asking for login credentials for a public share that needs none?
-Why am I getting this error regardless of what I enter, even the root credentials for the SAMBA server?

No doubt I'm missing something - either a misconfiguration somewhere or a fundamental misunderstanding of how a desktop Linux handles this kind of thing.

For clarity:
-No, I don't want to change how my server handles shares, just to suit an OS I'm testing when everything else is happy.
-No, I don't want these to be password-protected or private shares - I want them automatically browsable and accessible by all.
-Just get to the bottom of what's wrong with my Mint set up and fix whatever the miscommunication with my server.

Having discovered Mint isn't as guilty of the keychain nonsense that has put me right off other distro's in the past (eg: I can install my favourite browser, Thorium, without a load of messing about trying to cure pesky password popups) I just need it to play nice with my network from my point of view...
...at that point I'm going to see if it will run Paint Shop Pro, via Wine or Virtualbox. If that irreplaceable for me Windows app will function under Mint, my next task will be to dual-boot it with the current Windows install on my main laptop...
...eventually with a view to migrating fully.

-On the minus side I've been trying to ditch Windows for something like 20 years, not because of Windows but because of MicroSoft.
-On the plus side this 'adventure' with Mint is the furthest I've gotten with a desktop Linux before giving up in disappointment.

I hope that's all the info anyone might need.

Many thanks in advance for any greatly appreciated help.

CM.

[charlesmouse]

Ah, am I dealing with a fundamental misunderstanding as to how Linux (Mint) goes about stuff?
As mentioned, when I click on the FILESERVER folder icon I get a 'login' dialogue - confusing as there is no password on this public SMB server, and nothing I do will get me in to that Samba server...

...what I'm expecting is something equivalent to what Windows does. Which is selecting the server will bring up a directory listing of all the individual SMB shares on that Samba server ...but is that an assumption to far..?

If I type something like smb://fileserver/Audio in to the address line I get another pointless pop-up. Then if I click 'connect' on that pop-up I'm in to that shared directory - hurrah! (sort-of)

Is this 'normal' Linux GUI behaviour? It's very clunky if so. Why have a list of available network servers at all if you can't just click though them but have to type in an explicit address to a specific folder anyway!?! (a folder you may not know is present if it's not presented to you as an option.)

-If this is 'abnormal' behaviour, how do I fix it?
-If this is 'normal' behaviour, is there a way to make it behave more sensibly? - ie: No pointless pop-ups and the GUI doing it's job instead of forcing me to type in a guess at an address.

Thanks again.

[altair4]

Interesting post.

It's unusual to get a prompt for credentials at the host level - it's almost as if you didn't have the "Bad User" option on the server's smb.conf.

It is usual to get a prompt for credentials for every access to a share even to one that doesn't require credentials. It doesn't look like yours it looks like this in Linux:

You would have to select Anonymous if it required no password.

And the initial "invalid argument" thingy is most likely because for the moment the gvfs backend that Mint uses defaults to using SMBv1 when it makes it's initial connection to a server. There is no SMBv1 on modern servers any longer so it errors.

That "bug" is bypassed when you ask for the server and it's share explicitly as you have done.

EDIT: although it's none of my business but as my granny always used to say: Every time you specify "force user = root" in smb.conf an angel loses it's wings"

[charlesmouse]

Ah! Thanks very much for the reply, I really appreciate it.

So... it seems whatever I've done it's not behaving normally - I'm actually pleased to hear it as otherwise using SMB network shares with Mint is going to be very clunky.
Just to clarify:
'Normal' behaviour should be that when I select the likes of FILESERVER in the Mint file manager I will get a directory listing of the shares available on that server that I can then select-through to access.
That I'm having to select specific shares by typing the full network address in to the address bar is not normal, I've just accidentally found a kludge for whatever is wrong with my set up.

Good! Now if anyone can help me get to the bottom of this I would be most grateful - in the meantime I'll keep fiddling. Thank you again.

PS
"EDIT: although it's none of my business but as my granny always used to say: Every time you specify "force user = root" in smb.conf an angel loses it's wings""
That's an understandable point... um, you're going to hate me for what I'm about to say, try to forgive me:
The version of Linux I have any experience with is DietPI - principally because it a very stripped-out low-resource use 'distro' that will run well on just about anything - it's my go-to 'distro' when I want a minimal system to provide a service of some kind. My ESXi server has several VM's, each doing a 'thing' or two for the rest of the network. Install, add the minimum packages to get that 'service' up and running, job done. Maybe add further semi-related 'services' to that install at a later date...
...so far so good...
...the horror comes with my default treatment of DietPi - I remove all accounts but for the root user and run everything as root with autologin! No more messing about with passwords or keychains, no more 'sudo', stuff just works, lovely! (security is handled at my discretion elsewhere)

I would do the exact same thing with a daily driver desktop distro like Mint if I had a better handle on how to go about it and I could be sure doing so wouldn't break a lot of stuff.

[altair4]

There are ways to bypass this issue with a credentials prompt for guest shares.

You could simply access the host and it's share ( i.e., smb://server/share ) then when prompted specify:

Connect as: Registered user

Username: guest
Domain: WORKGROUP
Password: xxx

Literally enter xxx.

Then select Remember forever.

You can also do a cifs mount - as in mount.cifs - and specify the "guest" option: See the Atutomount in /etc/fstab: section in this Howo: Automount Samba Shares with CIFS:

[charlesmouse]

Thanks very much for that, I shall do a bit more fiddling courtesy of your guidance..

I thought I'd do a fresh reinstall and update just to see if I'd done something to Mint to cause this behaviour. Here's what I found:

Behaviour in Windows I possibly incorrectly assumed would be similar in Mint.

My Shares as 'seen' by Windows 11


What happens when I select the FILESERVER Samba Server...

...it opens to reveal the shared folders on that server.


Now on to the behaviour I see in my fresh Mint install, the same as before:

Recognised Network Shares

Somewhat the same as with Windows - Samba only at this point

Select the FILESERVER..

...and I get this unexpected pop-up, rather than the shared folders.

Try to 'connect' a couple of times...

...and this is the error I get.

If instead I type the full address of a shared folder on Server...


I get this redundant authentication request.


Although in selecting 'Connect' I reach the contents of that SMB-shared folder...

...and it appears on the backdrop, which is nice.

All this is entirely unfamiliar to me. So posting to check if this is normal / abnormal behaviour, and what may / may not be done about it...
...in the meantime I'll go investigate the kind suggestion above.

Thanks again.

[altair4]

I'm still not sure why you are getting the initial prompt for credentials when accessing the FILESERVER host to get the list of shares.

I took my Debian 12 server and replaced my smb.conf with yours just to see if perhaps all the MacOS options you selected had something to do with this but I just can't reproduce it.

The second prompt and all your other observations are normal.

[RowlandP]

I'm still not sure why you are getting the initial prompt for credentials when accessing the FILESERVER host to get the list of shares.

I took my Debian 12 server and replaced my smb.conf with yours just to see if perhaps all the MacOS options you selected had something to do with this but I just can't reproduce it.

The second prompt and all your other observations are normal.

There is a very good reason why the 'MacOS options' don't appear to be doing anything, they aren't

The OP has the required 'vfs objects' turned off and without that, the parameters do nothing, the OPs effect global part of the smb.conf is this:

Code: Select all

[global]
	map to guest = Bad User
	server min protocol = SMB2
	workgroup = LAN

And the 'protocol' line is a bit superfluous, the default is:

Code: Select all

server min protocol = SMB2_02

[altair4]

There is a very good reason why the 'MacOS options' don't appear to be doing anything, they aren't

The OP has the required 'vfs objects' turned off and without that, the parameters do nothing, the OPs effect global part of the smb.conf is this:

Code: Select all

[global]
	map to guest = Bad User
	server min protocol = SMB2
	workgroup = LAN

I don't want to hijack this thread but I do have a question of my own.

Almost always testparm has given me what I thought it should have given me: "What is the impact of my smb.conf relative to the default settings"

In this case running testparm still results in all those "MacOS options" present in the output. Is my understanding of testparm flawed?

[RowlandP]

There is a very good reason why the 'MacOS options' don't appear to be doing anything, they aren't

The OP has the required 'vfs objects' turned off and without that, the parameters do nothing, the OPs effect global part of the smb.conf is this:

Code: Select all

[global]
	map to guest = Bad User
	server min protocol = SMB2
	workgroup = LAN

I don't want to hijack this thread but I do have a question of my own.

Almost always testparm has given me what I thought it should have given me: "What is the impact of my smb.conf relative to the default settings"

In this case running testparm still results in all those "MacOS options" present in the output. Is my understanding of testparm flawed?

There are two versions of 'testparm', one is just that 'testparm', the other is 'samba-tool testparm', for most users the first is the one to use, the latter should only be run against a Samba AD DC smb.conf

Neither version is perfect, whilst it will remove parameters that are set to defaults, it doesn't know all the defaults, especially if they are 'vfs' defaults, so it outputs them.

[charlesmouse]

Hello all.
I just wanted to say "Thank you" for all the kind help - I've found a solution I'd like to share in case it's of any use to others:

I don't know if this is a bug in the Nemo file manager or just a behaviour I don't get, but I thought I'd start trying other files managers just in case. Dolphin first on the list for no better reason than it was first on this list of options: https://itsfoss.com/file-managers-linux/

...so I installed Dolphin as instructed on an brand new Mint install and it's smb file browsing works exactly as I hoped. (Nemo still not, so I uninstalled it)
I might as well try a few other file managers while I'm at it to see if there's one that suits me even better. I remember maybe 15 years ago finding a RiscOS-alike file and desktop manager for Linux. I wonder if it's still supported / developed?

As an aside, one of the numerous reasons I gave up on Zorin 17 was because it's file manager (not Nemo, I think) had the same unfortunate behaviour.

Thank you again for your help.

PS
So there you go, one step closer to finally ditching Microsoft after all these years. I have no issue with Windows as a base OS, just MicroSoft.

The last hurdle before I go dual-booting is to see if there's any way I can get Paint Shop Pro to work - indispensable for me, there are no viable alternates and sadly no native Linux version. I can't get it to run under Wine (maybe me) but Gnome-Boxes looks intriguing, even if using a VM within Linux to run Windows rather defeats the point.

[AndyMH]

to see if there's any way I can get Paint Shop Pro to work - indispensable for me, there are no viable alternates

Have you tried pinta, or more advanced, krita?