Hello, I hope someone can solve this:
I have a shared folder on a Mint 18.1 server.
Samba configured for user level access and only my username allowed to use the share. Share is browsable
I'm trying to open the share from a Mint 18.2 laptop using nemo and I have two issues:
1. can't browse the network, with an error "Failed retreiving share list from server: file or directory does not exist" (translated from Italian don't know if it is exactly the same in English)
2. searching directly smb://ser.ver.ip.addr I do see the shared folder, but when trying to double click to open I have the window asking for Anonymous or registered user, I choose "registered" and insert the password, but I cannot actually open the share, because nemo does not authenticate falling back to the ask-for-password window
what i tried so far:
mount via terminal command "mount -t cifs etc. etc." --> WORKS perfectly
make the same share available to anyone with no password on the 18.1 server and access via nemo --> WORKS
trying to open the share via nemo from a different laptop with same Mint version (18.2) and nemo version (3.4.7) than the non-working laptop --> WORKS perfectly both network browsing and direct ip address link, same user and password
I guess the problem is that my installation of Mint lacks some plugin, authentication package or something like that
I had a similar issue accessing from a MacOS Sierra to a samba share, there I solved pointing the Finder to cifs://ip.addr.ess instead of smb://ip.addr.ess
Can anyone help me?
can access samba share via command line but not via nemo [SOLVED]
Forum rules
Before you post please read how to get help
Before you post please read how to get help
can access samba share via command line but not via nemo [SOLVED]
Last edited by tuzzer on Sat Nov 04, 2017 7:59 pm, edited 1 time in total.
Mint 18.2 Cinnamon 64bit on MacBookPro (early2008) - 3Gb RAM - 250Gb HD - NVIDIA GeForce 8600M
Re: can access samba share via command line but not via nemo
Use the native Linux ( and macOS ) way of accessing hosts by name: viewtopic.php?f=157&t=185410#p9604821. can't browse the network, with an error "Failed retreiving share list from server: file or directory does not exist" (translated from Italian don't know if it is exactly the same in English)
Which password? The Linux login password for that user or the samba password for that user?2. searching directly smb://ser.ver.ip.addr I do see the shared folder, but when trying to double click to open I have the window asking for Anonymous or registered user, I choose "registered" and insert the password, but I cannot actually open the share, because nemo does not authenticate falling back to the ask-for-password window
In other words did you add the registered-user to the samba password database?
Code: Select all
sudo smbpasswd -a registered-user-name
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
Re: can access samba share via command line but not via nemo
Tried both passwords, no result with both of themaltair4 wrote: Which password? The Linux login password for that user or the samba password for that user?
In other words did you add the registered-user to the samba password database?Code: Select all
sudo smbpasswd -a registered-user-name
I had added the user when configured samba on the server machine, and this user and samba password are those working via command line
I'll try and let You know.altair4 wrote: Use the native Linux ( and macOS ) way of accessing hosts by name: viewtopic.php?f=157&t=185410#p960482
Thank You very much for your help
Mint 18.2 Cinnamon 64bit on MacBookPro (early2008) - 3Gb RAM - 250Gb HD - NVIDIA GeForce 8600M
Re: can access samba share via command line but not via nemo
Followed he instructions for the avahi method.tuzzer wrote: I'll try and let You know.
I find it nicer than the "browse workgroup" method, and I'll use in the future
But it didn't solve the authentication issue
At last, I have remembered that some days ago I installed gadmin-samba on the laptop which is giving the problem, to configure samba via gui, then removed gadmin-samba (even using the purge option), but for some reason its smb.conf file was still there.
I replaced it with the original smb.conf file and now authentication with samba user and password is working fine.
I guess something was wrong (at least for my needs) in the password authentication protocol or configuration or something.
I'm not this expert with samba and always used the standard basic conf file
I'll try to read and understand the options set up by gadmin-samba with its conf file
Thank You for your time
Mint 18.2 Cinnamon 64bit on MacBookPro (early2008) - 3Gb RAM - 250Gb HD - NVIDIA GeForce 8600M
Re: can access samba share via command line but not via nemo [SOLVED]
I think you will be wasting your time. Gadmin-samba is hopelessly out of date written originally for Samba Version 2 and never updated. We are now at Version 4 of Samba so many of the parameters used in gadmin-samba no longer exist.I'll try to read and understand the options set up by gadmin-samba with its conf file
I installed gadmin-samba and ran it to show you what is wrong with it. Please note that the the utility
testparm
is used to run diagnostics on smb.conf. When I run testparm -s
it outputs a series of errors referencing many things that no longer exist:
To be frank about this the only reason gadmin-samba is still in the repository is because no one - not in Mint, Ubuntu, or Debian - knows anything about Samba.WARNING: The "null passwords" option is deprecated
Unknown parameter encountered: "password level"
Ignoring unknown parameter "password level"
Unknown parameter encountered: "update encrypted"
Ignoring unknown parameter "update encrypted"
WARNING: The "idmap uid" option is deprecated
WARNING: The "idmap gid" option is deprecated
...
...
WARNING: socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
This warning is printed because you set one of the
following options: SO_SNDBUF, SO_RCVBUF, SO_SNDLOWAT,
SO_RCVLOWAT
Modern server operating systems are tuned for
high network performance in the majority of situations;
when you set 'socket options' you are overriding those
settings.
Linux in particular has an auto-tuning mechanism for
buffer sizes (SO_SNDBUF, SO_RCVBUF) that will be
disabled if you specify a socket buffer size. This can
potentially cripple your TCP/IP stack.
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.