NOTE: I have read probably up to 50 different pages describing how to setup public Samba share in the span of 2 YEARS and nothing ever worked for me. I don't know how much RTFM I need to set this stuff.
I need/want to setup a completely open public file share on my home server for two workstations.
Setup is as follows:
Server:
- Debian Wheezy
sudo smbd --version
gives meVersion 3.6.6
.- 2 local partitions which I want to share, formatted in NTFS due to being old and taken from Windows machine. I cannot format them to ext* FS because they have a lot of data I cannot (yet) move anywhere else.
- machine named "homeserv" for lack of originality.
Client:
- Debian Testing (Jessie)
- Windows 7 (2 different machines). In fact, my machine is Debian/Windows dualboot, and my wife's machine is Windows only.
My smb.conf after distillation looks as follows (verbatim, nothing else is there):
[global]
workgroup = WORKGROUP
security = user
map to guest = Bad User
[disk1]
comment = Disk 1 on 400GB HDD
path = /media/disk1
browsable = yes
guest ok = yes
read only = no
create mask = 0755
[disk2]
comment = Disk 2 on 400GB HDD
path = /media/disk2
browsable = yes
guest ok = yes
read only = no
create mask = 0755
On both client machines, in both Debian and Windows I get the same result: login/password dialog. NO COMBINATION of security = user
, map to guest = Bad user
, security = share
, guest ok = yes
and such helped.
Windows 7 shows login/password dialog right after I click on the shared machine in network neighborhood. smb://homeserv/
file path in Debian (in any file browser) shows me two folders: disk1
and disk2
, as intended, by trying to open them bring the login/password dialog.
So, what I lack in the scheme to NOT HAVE to enter login/password? This is usability question, I will not create a user-based authentication for file junkyard.
OK, I have found an answer myself.
As this is absolutely not obvious from the docs and HOWTOs and whatever, the reason this thing asks for password is because it cannot map guest user to the owner of the directory being shared.
I have NTFS partitions which I need to mount RW so I used the following setup in my
/etc/fstab
:The most important pieces of config are
uid
andgid
(maybe onlyuid
, don't know). They are set to the UID and GID of the userjonnie
set up on the server (obviously not root). So, when ntfs-3g will mount these disks, everything will be owned by him.After that, I have added this user to the Samba registry (or maybe created new identical one, don't care):
It asked for password, I have entered the same as for the main system.
After that, I have added the
force user
andforce group
settings to thesmb.conf
:So, most important piece of config relevant to me was
force user
.Courtesy of the Samba HOWTO
The config can be shorter:
Create unix user jonnie
Create smbuser
Create the Linux directory to share
Change the owner of the directory to jonnie
smb.conf
All files are owned by jonnie and everyone has rw access to the files.
The quick and dirty way to have an open Samba share is to have:
and have shares defines as such:
Restart the daemon.
For Windows 7 clients, as of 2014, I've needed to set the domain policy: digitally sign communications from always to DISABLE.
The accepted answer by "hijarian" at the time of writing is not ideal for the main reason that if the share is writable, then you cannot know which user wrote to the share. If it is a guest mount, then who cares about security and you can stop reading this now. If you care about security, read on...
By default, Windows passes the username and password of the currently logged-in user. This means that the password set with
smbpasswd
should match that of the user's password on the Windows client. The password may not be the empty string (at least I have not found a way to force this while also passing the authentication step).File shares are often group-oriented (group of users need access to the same data). This is why I prefer to implement shares by groups (not by users like in most documentation):
Note the
@smbmedia
. This means that anyone in the groupsmbmedia
may access this share. I havecreate mode
anddirectory mode
in there, but its mostly for good measure and redundant.Because this share is writable, the default umask will apply. I like to override this because I want ensure that new files are owned by the group
smbmedia
and the user should be set to the user who created the file (for record keeping).Set the sticky bit to ensure new directories keep the same ACLs (which we'll set next. CAVEAT: Without
create mode
anddirectory mode
, and relying on only ACLs, note that ACLs cannot set the group sticky bit. The group stick bit will therefore only work for new directories at 1 level below the base level of the share. This means that newly created directories at level 1 will have the ACLs applied minus the group sticky bit, so that level 2 directories will assume the primary group permissions of the user that created the new directory, and not necessarily the "shared" group permissions (something like this). There are two ways to deal with this: One way it to use something likeinotify
to watch for new directories and apply the group sticky bit on newly created directories recursively. The other way is to push the responsibility to your samba daemon by using something likedirectory mode = 2775
to force the group sticky bit on all newly created directories.Set the default ACLs for new files to ensure the group remains constant
Now you can be sure that new files will be created with the correct permissions so that they can be seen and changed by smb client users. This will allow anyone in the
smbmedia
group to change files owned by other people, however. You can adjust the ACLs accordingly.List of other things to do: