pavement

Samba, Configuration

From FreeBSDwiki
(Difference between revisions)
Jump to: navigation, search
Line 56: Line 56:
 
'''log file = /var/log/log%m''' - Tells Samba to create log files for each machine that connects in the var/log/ directory. For example, if a machine with the name of ''johndesktop'' connected, a log file named '''log.johndesktop''' would be created in /var/log, and appropriate entries for that machine would be made there.
 
'''log file = /var/log/log%m''' - Tells Samba to create log files for each machine that connects in the var/log/ directory. For example, if a machine with the name of ''johndesktop'' connected, a log file named '''log.johndesktop''' would be created in /var/log, and appropriate entries for that machine would be made there.
  
Second line: limits the size of each log files to x kilobytes, in this case 50. This is so you don't find a gig of logs a year down the road.
+
'''max log size = 50''': limits the size of each log files to x kilobytes, in this case 50. This is so you don't find a gig of logs a year down the road.
  
 
'''security = user''': This is '''important''', and integral to simple networking between your new Samba server and your Windows machines.
 
'''security = user''': This is '''important''', and integral to simple networking between your new Samba server and your Windows machines.
Line 123: Line 123:
  
 
That's it - you've defined all the important parts of the share for Samba, so it knows where to find it, and how to limit users' access to it.
 
That's it - you've defined all the important parts of the share for Samba, so it knows where to find it, and how to limit users' access to it.
 +
 +
Test your new config with [[testparm]], which is a Samba tool that lets you validate your smb.conf.
 +
 +
<pre>Oyabun# testparm</pre>
 +
 +
I won't list the results here, but you should see a list of your shares. If there are any warnings or error messages, you'll want to analyze and correct the problem. Lastly, testparm will dump your smb.conf to the console.
  
 
---
 
---
Line 144: Line 150:
 
'''valid users = @private''' - This prevents anyone who is not a member of @private from having access to this share. Because '''public = no''', people who are NOT members of @private won't even see this share when they browse the server.
 
'''valid users = @private''' - This prevents anyone who is not a member of @private from having access to this share. Because '''public = no''', people who are NOT members of @private won't even see this share when they browse the server.
  
== User accounts and permissions in BSD and Samba ==
+
That's it, you now have two distinct shares set up, with two distinct sets of criteria to determine who gets access to those shares from a windows machine.
 +
 
 +
== User accounts in BSD, Samba, and Windows ==
 +
 
 +
There are two parts to this step, adding matching matching user accounts to the Samba server and the various windows machines, and adding matching Samba passwords to the Samba server for each user. '''Usernames and passwords must match exactly between the client Windows machines and the Samba server.'''
 +
 
 +
Let's say ''Bob'' logs onto his windows machine with the username "''bob''" and the password "''syeruncle''". He already has an existing windows account, obviously, so you don't need to set that up, but if he didn't, you would. Bob is going to be a member of the @public group.
 +
 
 +
The quickest way to do this is to use '''/stand/sysinstall''' to add the user. You can also add users via the command line with [[adduser]]. Make sure you make each user a member of the appropriate group!
 +
 
 +
''bob'' will be a member of @public
 +
''greg'' will be a member of @private
 +
 
 +
Now we need to use [[smbpasswd]] to validate these users in the eyes of Samba.
 +
 
 +
Make sure you are root before doing the following:
 +
 
 +
<pre>Oyabun# su bob
 +
Oyabun# smbpasswd
 +
New SMB password:
 +
Retype new SMB password:
 +
Password changed for user bob.
 +
Oyabun# exit</pre>
 +
 
 +
In this example, as root, I switched to bob, then used the [[smbpasswd]] command to define my Samba password. It asked me to enter a password, asked me to confirm it, then accounced that the password was changed. Then I typed '''exit''' to exit the shell-as-bob, return to my root shell.
 +
 
 +
Repeat this process for ''greg'', entering greg's password.
 +
 
 +
---
 +
 
 +
Finally, we're done. We have shares set up, user accounts are in place, and everything is ready to go - now we just have to start Samba. This is easy. A startup script was placed in "'''/usr/local/etc/rc.d/'''", with a likely name of "''samba.sh.default''".
  
== Configuring a Windows machine with matching settings ==
+
Let's rename it, and run it.
  
Ideally, you want the user account and password on a windows machine attempting to make a connection to have a matching user account and password on the Samba server. In fact, if it's a Win9x machine, it's a '''requirement'''. Windows 2000 and XP will both challenge the user to supply proper credentials if their username and password don't match any that Samba and BSD recognize as valid, but Windows 95 and 98 both will simply not work - it's imperative that a matching user account exist on the Samba server.
+
<pre>Oyabun# cd /usr/local/etc/rc.d
 +
Oyabun# mv samba.sh.default samba.sh
 +
Oyabun# /usr/local/etc/rc.d/samba start
 +
SambaOyabun#
 +
Oyabun#</pre>
  
 +
First, rename the file from samba.sh.default to samba.sh. Then, execute it, using the full path (it will complain otherwise). If all  went well, after execting ''samba.sh start'', you'll see ''Samba'' inserted before the name of your server at the next shell prompt.  This means Samba is indeed running, and that you can now attempt to connect to this machine from your Windows machines. You should do so, testing the various accounts you have set up to make sure they can all connect.
  
 +
Congrats, you now have a Samba server.
 
[[Category:Common Tasks]]
 
[[Category:Common Tasks]]

Revision as of 23:16, 23 August 2004

Samba - Simple Configuration

See also: Samba - Samba_Installation

This article will walk you through a quick setup of Samba - creating directories to be shared, telling Samba to share those directories, how to limit access to different shares, and finally, how to set up a windows machine to have unfettered access to appropriate shares based on the currently logged in user. This article assumes you have a fresh, unconfigured install (Samba_Installation) of Samba to work with.

Setting up your shares on the machine

First we need to decide what we're going to share, or at the very least, where the shares will actually reside. The simplest way to do this is to simply create a new directory in an easy to remember place, say, /usr. You can either share that new folder directly, or create several new directories within it, and limit access to each directory based on criteria I will make clear later in this article. For now, let's assume you have two sets of documents, public and private, and that you want to limit users' access to those documents based on who they are - they can either access both, or just public. So:

Oyabun# mkdir /usr/smbroot
Oyabun# mkdir /usr/smbroot/public
Oyabun# mkdir /usr/smbroot/private

The first command creates the /usr/smbroot/ directory, which will hold all of your shares. The second command creates the public directory, which all users will be able to access, and the third command creates the private directory, which only select users will be able to access.

Now we need to set permissions on these directories. The permissions article goes into great detail about permissions, but a quick run through here will be fine. We'll use chown to change ownership of these two directories now. We'll assume you have or will set up two groups for your users, one group named public, and another named private.

Oyabun# chown :public /usr/smbroot/public
Oyabun# chown :private /usr/smbroot/private

The first command sets the owning group of /usr/smbroot/public to :public. The second command assigns ownership of /usr/smbroot/private to the group :private.

Now we need to set the actual permissions with chmod.

Oyabun# chmod 770 /usr/smbroot/public
Oyabun# chmod 770 /usr/smbroot/private

Same permissions for each directory, broken down thusly: The first 7 is the 'owner' flag, and 7 means read/write/execute. The owner can do all of those things. The second 7 is the group flag, meaning the owning :group can also r/w/x. The third character, 0, is in the 'rest of the world' position, meaning anyone who is NOT the owner, and NOT a member of the owning group. They can't read, they can't write, and they can't execute. Since we're not setting up anonymous access, we don't want users who aren't explicitly defined as having access to actually have any access, and this will accomplish that.

Configuring Samba to use your shares and interface with local Win.X machines

Ok, now we have the shares set up appropriately, we just need to define them for Samba. In /usr/local/etc/, there is a file named "smb.conf.default". This is a seriously large and complex file with waaaay more options than the average user will ever need to get Samba up and running. I highly suggest you go through it, as it has several examples of methods used to share directories, and access restriction methods. For this article, we'll be writing an smb.conf from scratch.

[global]

The first section of your new smb.conf file should look like this:

[global]
workgroup = WORKGROUP
server string = NameOfServer
log file = /var/log/log.%m
max log size = 50
security = user
encrypt passwords = yes
socket options = TCP_NODELAY
preferred master = yes

[global] is a header in the file, telling Samba all entries after that, before the next [section] are to be globally applied.

workgroup = WORKGROUP - Specifies which Windows Workgroup to make the server a member of.

server string = NameOfServer - Names the server. This is the name you'll see in network neighborhood. For example, my smb.conf names my server 'Oyabun'. (cuz it's the boss!)

log file = /var/log/log%m - Tells Samba to create log files for each machine that connects in the var/log/ directory. For example, if a machine with the name of johndesktop connected, a log file named log.johndesktop would be created in /var/log, and appropriate entries for that machine would be made there.

max log size = 50: limits the size of each log files to x kilobytes, in this case 50. This is so you don't find a gig of logs a year down the road.

security = user: This is important, and integral to simple networking between your new Samba server and your Windows machines.

ecrypt passwords = yes: This is also important - passwords must be encrypted for each machine to successfuly negotiate login credentials with your Samba server.

socket options = TCP_NODELAY: This is not required, but the Samba documentation within smb.conf.default suggests this may yield better performance, so I include it.

preferred master = yes: Windows machines "elect" master browsers, which is a machine which takes on the duties of describing to other machines what all the machine names and locations are. Since your Samba machine is likely to be the sanest machine on your network, it's a good idea to have it 'fudge' the election results and always be the master browser. This option causes Samba to force a browser election when it starts up, and cheats to give it a higher chance of 'winning'.

And that's the global section. Now, on to actually setting up shares.



[homes]

If you want your users to be able to access the home directories of their FreeBSD user accounts, add a [homes] section. If you do NOT want individual users to have private storage areas, do not include this section.

[homes]
comment = Home Directories
browseable = no
writeable = yes

The mere existence of [homes] tells Samba to allow users to have access to their home directories via network sharing. If it's not there, they don't have it.

comment = Home Directories is a description for the [section], and will show up in Windows Explorer under the 'comment' field.

browseable = no means users other than the owner can't see or browse the share. (I can't see your home directory, you can't see mine, but we're both valid users.) Similar in purpose and execution to the 'My Documents' folder Windows users are familiar with. Each user has their own 'My Documents' folder.

writeable = yes means users can save files in their home directories from across the network.

That's it, setting up home directories is simple.

---

[public]

Now we'll set up the publicly accessible folder, located at /usr/smbroot/public/.

[public]
comment = Public
path = /usr/smbroot/public
public = no
writeable = yes
write list = @public
directory mask = 0770
create mask = 0007

[public]: "Create a new share named 'Public', which will look like a folder named 'Public' in Network Neighborhood.

comment = Public: Same deal, this fills the 'comment' field in windows explorer / network neighborhood, when you're looking at the share.

path = /usr/smbroot/public: This tells samba exactly where on the local machine to store files for this share. This is pretty important.

public = no: This is sort of counter-intuitive, but you don't want this set to yes.

writeable = yes: This tells Samba to let authorized users write to the directory.

write list = @public: Lists the users and @groups allowed to write here. This is important! To define this further, or add more users or @groups, you'd write the line like this: "valid users = joe bill @public @friends @dogs".

directory mask = 0007: This causes directories created by network users to have permissions of 770, and anyone can delete them. To make only the owner and root@sambaserver have permission to remove them, change this to 1007. The last three digits of the mask '007' in this case, are subtracted from permissions of 777, digit by digit. So, 777 - 007 = 770.

create mask = 0007: Same deal, only this applies to files. Again, set it to '1007' to only allow the owner and root@sambaserver permission to delete the file.

That's it - you've defined all the important parts of the share for Samba, so it knows where to find it, and how to limit users' access to it.

Test your new config with testparm, which is a Samba tool that lets you validate your smb.conf.

Oyabun# testparm

I won't list the results here, but you should see a list of your shares. If there are any warnings or error messages, you'll want to analyze and correct the problem. Lastly, testparm will dump your smb.conf to the console.

---

[private]

Now we'll set up the private share. It will actually look just like the public share, with a few small changes.

[private]
comment = Private
path = /usr/smbroot/private
public = no
writeable = yes
valid users = @private
write list = @private
directory mask = 0770
create mask = 0007

Obviously we defined the basic stuff like [private] and where the directory is.

valid users = @private - This prevents anyone who is not a member of @private from having access to this share. Because public = no, people who are NOT members of @private won't even see this share when they browse the server.

That's it, you now have two distinct shares set up, with two distinct sets of criteria to determine who gets access to those shares from a windows machine.

User accounts in BSD, Samba, and Windows

There are two parts to this step, adding matching matching user accounts to the Samba server and the various windows machines, and adding matching Samba passwords to the Samba server for each user. Usernames and passwords must match exactly between the client Windows machines and the Samba server.

Let's say Bob logs onto his windows machine with the username "bob" and the password "syeruncle". He already has an existing windows account, obviously, so you don't need to set that up, but if he didn't, you would. Bob is going to be a member of the @public group.

The quickest way to do this is to use /stand/sysinstall to add the user. You can also add users via the command line with adduser. Make sure you make each user a member of the appropriate group!

bob will be a member of @public greg will be a member of @private

Now we need to use smbpasswd to validate these users in the eyes of Samba.

Make sure you are root before doing the following:

Oyabun# su bob
Oyabun# smbpasswd
New SMB password:
Retype new SMB password:
Password changed for user bob.
Oyabun# exit

In this example, as root, I switched to bob, then used the smbpasswd command to define my Samba password. It asked me to enter a password, asked me to confirm it, then accounced that the password was changed. Then I typed exit to exit the shell-as-bob, return to my root shell.

Repeat this process for greg, entering greg's password.

---

Finally, we're done. We have shares set up, user accounts are in place, and everything is ready to go - now we just have to start Samba. This is easy. A startup script was placed in "/usr/local/etc/rc.d/", with a likely name of "samba.sh.default".

Let's rename it, and run it.

Oyabun# cd /usr/local/etc/rc.d
Oyabun# mv samba.sh.default samba.sh
Oyabun# /usr/local/etc/rc.d/samba start
SambaOyabun#
Oyabun#

First, rename the file from samba.sh.default to samba.sh. Then, execute it, using the full path (it will complain otherwise). If all went well, after execting samba.sh start, you'll see Samba inserted before the name of your server at the next shell prompt. This means Samba is indeed running, and that you can now attempt to connect to this machine from your Windows machines. You should do so, testing the various accounts you have set up to make sure they can all connect.

Congrats, you now have a Samba server.

Personal tools