Samba, Configuration
m (correcting a typo) |
|||
| Line 113: | Line 113: | ||
"valid users = joe bill @public @friends @dogs". | "valid users = joe bill @public @friends @dogs". | ||
| − | '''directory mask = 0750''': The directory mask setting controls the '''most permissive''' setting Windows clients are allowed to give a directory. In this example, the mask is set to | + | '''directory mask = 0750''': The directory mask setting controls the '''most permissive''' setting Windows clients are allowed to give a directory. In this example, the mask is set to 750, so a client can set read, write, and execute permissions to anything it wants to for the directory's owner; but for the group the Windows client can only set read and execute permissions, and since the "world" bit is set to 0, the Windows client will be unable to set any allowable permissions at all for "world" (neither the owner nor the group) for that directory. Note that the windows client is free to set ''less'' permissive settings on the directory - if it wanted to, it could still deny access to the owner or group; it just can't ''give'' access more permissive than that specified by the mass. |
'''create mask = 0750''': Same deal, only this applies to files. | '''create mask = 0750''': Same deal, only this applies to files. | ||
Revision as of 16:24, 3 December 2004
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 Samba Installation to work with.
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.
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 = 0770
[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 = 0750: The directory mask setting controls the most permissive setting Windows clients are allowed to give a directory. In this example, the mask is set to 750, so a client can set read, write, and execute permissions to anything it wants to for the directory's owner; but for the group the Windows client can only set read and execute permissions, and since the "world" bit is set to 0, the Windows client will be unable to set any allowable permissions at all for "world" (neither the owner nor the group) for that directory. Note that the windows client is free to set less permissive settings on the directory - if it wanted to, it could still deny access to the owner or group; it just can't give access more permissive than that specified by the mass.
create mask = 0750: Same deal, only this applies to files.
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 = 0770
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, and Greg will be a member of @private.
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 or pw. Make sure you are root before trying to add user accounts or Samba accounts, and remember to make each user a member of the appropriate group!
Oyabun# pw useradd bob -g public Oyabun# pw useradd greg -g private
Now we need to use smbpasswd to validate these users in the eyes of Samba.
Oyabun# smbpasswd -a bob New SMB password: Retype new SMB password: Password changed for user bob.
In this example, as root, I used the smbpasswd command to create a Samba account for bob. It then asked me to enter a password for the new user, asked me to confirm it, and announced that the password was changed.
Repeat this process for greg, entering greg's password.
If greg and bob are not really unix users at all, but only windows users that you want to be able to access Samba shares, you may wish to consider making sure they can't use the system accounts you created for them to actually log in to the box. For example:
Oyabun# pw usermod bob -s /sbin/nologin Oyabun# su bob This account is currently not available. Oyabun#
In this example, we set the bob account's default shell to /sbin/nologin, and then checked to make sure that account really couldn't shell into the box by using su to see what would happen if someone tried.
---
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.
See also: Samba - Samba_Installation
