![[img]](images/local-profiles.png)
| The Unofficial Samba HOWTO | ||
|---|---|---|
| Prev | Next | |
To effectively manage your Samba/Windows collection of computers, it is critical that you understand how Windows NT/2000/2003 Servers provide security through the use of Users and Groups. Specifically, you must be aware that there is a difference between the following four different types of Users and Groups:
Local Users
Local users are accounts that are unique to a single workstation. Each Windows 2000/XP workstation has two built-in Users: Administrator and Guest. Local Users are not available on Domain Controllers.
Local Groups
Local groups are groups that are unique to a single workstation. Each Windows 2000/XP workstation has several built-in Groups: Administrators have complete and unrestricted access to the workstation; Power Users have most administrative powers with some restrictions and can run legacy applications in addition to certified applications; Users are prevented from making accidental or intentional system-wide changes, and can run certified applications but not most legacy applications; the Guests Local Group actually has the same access permissions as the Users group (something that is often overlooked). Local Groups are not available on Domain Controllers.
Domain Users
Domain users are accounts that are created on a Windows NT/2000/2003 Server that is acting as a Primary Domain Controller. Samba mimics this behavior by treating every user in smbpasswd(8) as a Domain User. If the user root is defined in smbpasswd, it is equivalent to the Administrator account on Windows NT/2000/2003.
Domain Groups
Domain groups are created on a Windows NT/2000/2003 Server that is acting as a Primary Domain Controller. Samba technically only has two Domain Groups: the root user, and everyone else. However, Samba mimics additional group behavior by honoring filesystem permission restrictions using the group membership information in/etc/groups -- see groups(1) for more information.
Samba has no knowledge of Windows 2000/XP Local Accounts; as far as it is concerned, there are only multiple users (defined in smbpasswd) and a single Administrator named root (if defined in smbpasswd). Samba also has no knowledge(nor does it care) about Windows 2000/XP Local Groups; all Samba group memberships are defined in /etc/groups.The reverse is also true -- Windows 2000/XP has no direct knowledge of Samba Domain Users or the /etc/groups file on the Samba box. Therefore,it is possible to log into the domain as root (not advised for the security conscious) yet not have any administrative authority over the Windows 2000/XP box!Under Windows NT/2000/2003 Servers, you can add Local Users, Global Users, and Global Groups to Local Groups. With Samba, you can add Local Users and Global Users to Local Groups. However, with both Windows NT/2000/2003 Servers and Samba Servers, you cannot add Local Users and Local Groups to Global Groups.One option to get around this is to select one account from Samba to add it to each Windows 2000/XP workstation's Administrators Local Group. This needs to be done on a per-workstation basis since Local Groups are just that -- local to the box itself, and to no one else.There is no way to do this from the Samba server (nor should there be) or even from a Windows 2000 Server.
If you'd like to enable roaming profiles for Windows 2000/XP, make the following changes to your smb.conf file (below). Note that this is strongly discouraged unless you know what you're doing (headache prevention)!
[global]
logon path = \\example-server\profile\%U
[profile]
create mode = 0600
csc policy = disable
directory mode = 0700
path = /home/profile
profile acls = yes
read only = no
Due to some changes introduced with Windows XP Service Pack 1, you must choose one of the following methods regarding how you intend to implement Roaming Policies:
If you're running your Samba server to act as a Primary Domain Controller (PDC) for Windows clients, you can have a batch file execute upon login. This can be enabled by adding the following to your smb.conf file:
[global]
logon script = logon.bat
[netlogon]
path = /home/netlogon
All login scripts must reside in the [netlogon] share and should be formatted to be readable by your Windows clients (seeLine Feeds CR/LF below). Here's a sample script which I've found to be quite useful:
@echo off NET TIME \\example-server /SET /YES NET USE F: \\example-server\PUBLIC /YES NET USE P: /HOME /YES
Another issue to become aware of with login scripts (among other things) is line feeds. Windows computers expect login scripts to end each line with windows-style line breaks; Linux expects shell scripts to end each line with UNIX line breaks.
Architecture Hex ASCII Definition DOS/Windows 0x0d 0x0a \r\n Carriage Return (CF), Line Feed (LF) Macintosh 0x0d \r Carriage Return (CF) UNIX 0x0a \n Line Feed (LF)
Technically, DOS files also end with a "\z" (0x22); but supposedly Windows discards or ignores this.
So why is this important? If you're working in a Linux/Windows mixed environment, you're bound to come across files that are littered with '^M' at the end of every line. This is the Windows command for 'newline', which uses a combination of a carriage-return (CR,control-R, or just plain '\r') and line-feed (LF, control-N, or just plain '\n'), affectionately known as CR/LF. Linux uses just the single LF.A good example of this in practice is when creating a shell program for Linux from windows workstation. For example:
#!/bin/sh
echo "Hello Sailor!"
If you wrote this with the Windows Notepad program, made it executable (chmod 755) and tried to run it under Linux,you'd get the following error message as a result of the embedded control characters at the end of each line:
: bad interpreter: Permission denied
The best solution is to never do this in the first place. The second best solution is to use Patrick Volkerding's todos utility.
Alternately, to convert from DOS to Linux, you can use either of these tricks:
cat dosfile | col -b > linuxfile perl -pi -e 's/\r\n?/\n/g' dosfile > linuxfile
It's worth noting that if you're running into this problem in the first place, it means you're working on a file that is being edited in both your Linux and Windows environments. As such, you should probably read the section on oplocks to prevent any data loss...
If you'd rather take care of things from the other side of the coin, you can simply use a text editor that can convert between DOS/Linux. For Windows, there's Jean-Pierre Menicucci's Editeur; for Macintosh, there's BBEdit.
"If you find a solution and become attached to it, the solution may become your next problem." -- Anonymous
Opportunistic locking essentially means that the client is allowed to download and cache the file on their hard drive while making changes; if a second client wants to access the file, the first client receives a break and must sync the file back to the server. This can give significant performance gains in some cases; in others, some programs insist on syncing back the contents of the entire file for a single change.Level1 Oplocks (aka just plain"oplocks") is another term for opportunistic locking.
Level2 Oplocks is a fancy way of saying that you are providing opportunistic locking for a file that will be treated as "read-only". Typically this is used on files that are read-only or on files that the client has no intention to write to (at least, not initially).
Kernel Oplocks are essentially a method that allows the Linux kernel to co-exist with Samba's oplocked files, although this is simplifying things a bit. SGI IRIX and Linux are the only two UNIX's that are oplock aware at the moment.Unless your system supports kernel oplocks, you should disable oplocks if you are accessing the same files from both Unix/Linux and Smb clients.
Regardless, oplocks should always be disabled if you are sharing a database file (e.g., Microsoft Access) between multiple clients, as any break the first client receives will result in the entire file needing to be sync'd (not just the single record), which will result in a noticeable performance delay and, more likely, problems accessing the database in the first place. Notably, Microsoft Outlook's personal folders (*.pst) react very badly to oplocks. If in doubt, disable oplocks and tune your system from that point.If client-side caching is desirable and reliable on your network, you will benefit from turning on oplocks. If your network is slow and/or unreliable, or you are sharing your files among other file sharing mechanisms (e.g., NFS) or across a WAN, or multiple people will be accessing the same files frequently, you probably will not benefit from the overhead of your client sending oplock breaks and will instead want to disable oplocks for the share.Another factor to consider is the perceived performance of file access. If oplocks provide no measurable speed benefit on your network,it might not be worth the hassle of dealing with them.
You can disable oplocks on a per-share basis with the following:
oplocks = False
level2oplocks = False
Alternately, you could disable oplocks on a per-file basis within the share:
veto oplock files = /*.mdb/*.MDB/
If you're having problems with oplocks as evidenced by Samba's log entries, you may want to play it safe and disable both oplocks and level2oplocks.
"I tried to get some documentation out of Digital on this, but as far as I can tell even _they_ don't have it;-)" --Linus Torvalds, in an article on a dnserver
Samba allows you to fine-tune how it works with your local network. This is primarily done by adjusting network sockets, which essentially tell Samba how to do low-level work with the local network. Since each network is different (wiring, switches, noise, etc), there is no "magic formula" that works for everyone. As a result, if you want to fine-tune Samba's performance for your specific network, you'll have to do some experimenting. For the diehard (and a great insomnia cure), you can read up on sockets via the manpage for socket(7).
Regardless, a good general starting point for you to try is:
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE
SO_RCVBUF=8192 SO_SNDBUF=8192
SO_RCVBUF & SO_SNDBUF
These two options define the maximum size of the send and receive buffers for Samba. Smaller buffers means more fragmented packets; larger buffers (up to a point) mean less fragmentation.
A good way to determine what's best for you is to create both a single 100 MB dummy file and 100 multiple 1 MB dummy files and test the time involved in sending/receiving both sets of files to and from the server. You'll want to make sure to stop and restart Samba each time to prevent any memory caching, just in case. By charting out the different response times for SO_RCVBUF and SO_SNDBUF you can find the optimal value for your specific network.
To create a single 100 MB test file:
dd if=/dev/zero of=testfile count=10240 bs=10240To create 100 multiple 1 MB test files:
#!/bin/sh
count=1
until [ "$count" -gt 100 ]; do
let "count += 1"
dd if=/dev/zero of=testfile${count} count=1024 bs=1024
doneAfter you've gathered your data, you'll want to chart it to find the optimal values for your specific setting. Once done, you can adjust your smb.conf file to have something like:
socket options = SO_RCVBUF=8192 SO_SNDBUF=8192
TCP_NODELAY & IPTOS_LOWDELAY
If you're running Samba on your local network, using these options would be a good idea. Adjust your smb.conf file to include:
socket options = TCP_NODELAY IPTOS_LOWDELAY
IPTOS_THROUGHPUT
If you're running Samba across a wide-area network, you can try experimenting with this option:
socket options = IPTOS_THROUGHPUT
SO_KEEPALIVE
This enables the sending of "keep-alive" messages on connection-oriented (tcp) traffic. If your connections are timing out, you can try experimenting with this option.
socket options = SO_KEEPALIVE
SO_REUSERADDRSO_BROADCASTSO_SNDLOWATSO_RCVLOWAT
You probably don't want to mess with these. If you're curious for more details, see the manpage on socket(7).
To join a Samba Domain, you will need to first make the following changes to your registry and reboot:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000
"signsecurechannel"=dword:00000000
When establishing your machine as a member of a domain, you'll need to add each Windows machine into your Linux machine's password file using vipw(8) or an equivalent. Regardless, the entry in /etc/passwdshould look something like this (below). Note the dollar sign ($) at the end of the workstation name; if your workstation's name is PC-LAB15, your entry in /etc/passwd should begin with PC-LAB15$ -- this is commonly overlooked. For information on the fields in /etc/passwd itself, see passwd(5).
myworkstation$:x:1200:300:Workstation:/dev/null:/bin/false
You should also have a group account specific to workstation-only accounts, using vigr(8) or an equivalent:
workstation::300:
And your entry in /etc/shadow (hint: try vipw -s) should look like:
myworkstation$:*:9797:0:::::
Finally, you need to add this account to the Samba password file. Note the lack of a dollar-sign here! The -m switch tells Samba that this is a machine account, and the -a switch tells it to add this account to the database. Note that this account won't have an initial password, so it's important to run this step immediately prior to having the workstation join your domain.
# smbpasswd -m -a myworkstation
To allow anyone to actually join, however, you'll need to add a smbpasswd entry for the user "root" -- this is required!Log in with an account that is a member of the Local Administrator's group. Note that this account should not exist on your Samba box.
Next, drop to a MS-DOS prompt and delete any existing NetBIOS connections. This will ensure that no ghosted connections to NETLOGON or $IPC exist:
NET USE * /DELETE /YES
In the Control Panel, open up System, locate the Computer Namesection and click Change. From here, you can join your Samba domain, which is the "Workgroup" parameter from your smb.conf file. You'll be prompted for a name and password of an account with permissions to join the domain; only the user account "root" will work here, and the account must exist both on your Linux box (of course) and in your smbpasswd file.
| Prev | Home | Next |
| Client Configuration | Troubleshooting |