I tried the option browseable=no
in my /etc/samba/smb.conf file. But after it was mounted, that share was still visible to other users through the mount point. But as from what I have learnt, setting directive browseable=yes
will make it publicly visible and setting it to no will not make it publicly visible. But why is it visible to other users thorugh the mount point even when I have set that directive to no?
Am I missing some concepts here? Please clarify.
Many thanks.
2 Answers
From the man page:
This controls whether this share is seen in the list of available shares in a net view and in the browse list.
Consider, do you also have "guest ok"?
If this parameter is yes for a service, then no password is required to connect to the service. Privileges will be those of the guest account.
This parameter nullifies the benefits of setting restrict anonymous = 2
See the section below on security for more information about this option.
Default: guest ok = no
If guest ok=yes
then unauthenticated users would have the guest account privileges, which might include viewing.
-
I didn't include the guest ok directive. And I think it is set to "no" by default. Commented Jul 10, 2017 at 17:05
-
So how do I restrict the mounted share so that it is not visible to other users? Commented Jul 10, 2017 at 17:06
-
That's probably dependent on the permissions of your mount point. If you mount on a directory that is world readable I expect all users on that system would be able to read it. Commented Jul 10, 2017 at 17:14
-
@AyushGoyal what are the permissions on your samba mount point? Commented Jul 10, 2017 at 17:20
-
It was created by root user, so using the defaults umask value 0022, the permission on my samba mount point is 0755. Commented Jul 10, 2017 at 17:26
[global]
# map to guest = Bad User
# 'Bad User' is not a valid linux account,
# this option will NOT have windows prompt user
# if windows account name does not match a valid
# linux account. Windows will respond with cannot
# access... their might be a problem with your network
# contact your administrator.
# will make it look like samba share is not there
# can be used as extra layer of security to force
# someone to know valid usernames on linux samba server
# map to guest = nobody
# nobody is a valid but locked linux account,
# When the given Windows user account name does not
# match any valid linux account then a prompt will
# pop up in Windows to give user chance to enter
# a valid linux username/password.
# useful if logged in as Administrator in Windows
# and need to access samba shares
# Warning: anyone on network can go \\yourlinuxserver
# and will get the popup and get a chance
# to enter your samba shares.
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
inherit acls = Yes
[scratch]
create mask = 660
directory mask = 770
inherit acls = Yes
path = /scratch
read only = No
browseable = Yes
[dataX]
create mask = 660
directory mask = 770
inherit acls = Yes
path = /data_private
read only = No
browseable = No
under the global section once you have chosen a choice for map to guest
as the first level of authentication, then browseable
yes/no becomes useful if you want to hide a share such that users must know the name of it. For example if the name of my linux server on the network is linuxserver123
then if someone goes
\\linuxserver123
in microsoft windows they will either get prompted or rejected based on map to guest
then allowed in if their username/password matches.
At this point the given user will see only their home account folder and not the homes
folder because browseable = no
for [homes]
.
And all authenticated users can see scratch
but they will NOT see the dataX
folder because of the browseable
setting.
For a user to get to dataX
or the folder /data_private
they must do \\linuxserver123\dataX
. If when you do just \\linuxserver123
in Windows and you want to see a dataX
folder in addition to scratch
and the one home account folder then set browseable=yes
for [dataX]
.
Once authenticated via Samba in linux as some given local linux account and with inherit acls = yes
for a given share, then that local linux account must have read/write/execute permissions to access the given shared folder(s) and files.