Important to remember, Samba only runs on Linux machines. They are seen as plain ol' Windows machines by Windows. Samba uses the smb protcol which is really Windows specific.
Also See: Samba How-To
Mapping a User's Filestore to Drive H

The filestore allocated to an individual user can be mapped on to a PC as a network 
drive, and BUCS recommend that it is mounted as Drive H. This is achieved as follows:
If you use Windows 95, 98 or ME

    * Click the Start Menu and select Run
    * Enter command in the Open: box
    * Click OK
    * Enter the following command into the Command Prompt;
      net use H: \\samba\homes
      this will ask for a password, enter your BUCS password.

If you use Windows NT, 2000 or XP

    * Click the Start Menu and select Run
    * Enter cmd in the Open: box
    * Click OK
    * Enter the following command into the Command Prompt (replacing username with 
	 your BUCS username);
      net use H: \\samba\homes /\username
      this will ask for a password, enter your BUCS password.

Important - Pay attention!
Try to connect to the "home/dir" using the command:
   net use t: \\root\home\users\mopie
The command might prompt you for a password if you are logged into Windows with a different password than your account on the Samba server. If so, enter the correct password and press enter.
Usernames, hosts, passwords and IP addresses, it is important to keep them straight.

Naturally depending on what you are doing, Check the:
As you can see, I stole the following from and added my own thoughts and comments. I thought that it was so good I wanted to make sure that it stayed available. Least as long as my site is still here. ACL as explained at ACLs on Linux explains, at least to me, why I had some much trouble getting my permission settings to work in my SuSE 9.1. They have made Linux more secure.
Access Control Lists allow fine-grained access control of filesystem objects by attaching a list of permissions which grant or deny specific capabilities to users or groups. There, of course are some problems in the current acceptance/usage of these new capabilities. Andreas Gruenbacher explains.

    This definition of PAM is included cause it is important... annnddd... I think it is part of my current problem(s). Anyway, you need to know it.

  PAM: pluggable authentication module 
    A UNIX programming interface that enables third-party security methods to be used.
    By using PAM,  multiple authentication technologies,  such as RSA,  DCE, Kerberos,
    smart card and S/Key,  can be added  without  changing any of the  login services,
    thereby preserving existing system environments.

Posted by raynet11 on 03-10-2004 05:26 PM:

Suse 9, samba integration with Microsoft

This document covers my adventures and pain in the integrating my Suse 9.X as a client and as a server in a Microsoft AD / Domain env. I decided to post this document to hopefully save others the pain. Feedback is welcome..

Suse 9.0 Window Active Directory / Domain How-to:

Purpose: This document will guide the setup of Suse 9.0 to support unified login as well as file and directory permission compatibility with in a Microsoft windows domain or active directory environment. And finally samba server setup..

Software and disclaimer:

This document was intended for Suse Linux 9.0 running samba-2.2.8a-107 only. Though there are common settings that can carry over to other Linux distributions this is what this document was written for. The pam structure differs the most between different Linux distribution's, documentation for redHat and Mandrake can be found on the web. Since this document was written the hard way through trial and error using bits and pieces of documentation found through books and on the web it may have faults that I am unaware of.

Packages used in the creation of this document:


Windows Structure:

Below I will define a fictional network, the network will consist of two machines the first listed is the domain controller running windows and the second machine will be our Linux workstation the domain name is also listed. The domain controller will also serve as the password server for the domain. Before you get started be aware that you must have a domain administrator account to put your Linux client in the domain.

Windows Side:

Domain Name:

Linux Side:


Before you get to far make sure that you have DNS name resolution to your domain controller from your Linux client, you should be able to ping it using the full domain name. (Note do not try to ping it by short name Linux is not using wins). If you cannot ping it then add the name to your hosts file located in the /etc directory.

Samba Configuration files:

1. From the console login as root using the su command.

# su

2. Change to the /etc/samba directory and make a backup of your smb.conf file.

# cp smb.conf

3. Edit the smb.conf global section, the following example uses MYCOMPANY as the domain and the domain controller is Substitute to suit your own network. Most of these lines will already be in your smb.conf file for the items that are not add them, for the lines that are different, change them. (note, you can add more then one password server just leave a space between the entries.)

workgroup = MYCOMPANY
os level = 2
time server = Yes
unix extensions = Yes
encrypt passwords = Yes
map to guest = Bad User
printing = CUPS
printcap name = CUPS
password server =
wins support = No
veto files = /*.eml/*.nwd/riched20.dll/*.{*}/
security = domain
netbios name = my-Linux

4. Next we will setup the winbind section of the file , add these parms after the global section.

#winbind options per rmgl 03-02-04:
winbind separator = +
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind cache time = 15
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/%D/%U
template shell = /bin/bash

#Allow password changing from Windows to update Linux System Password:
unix password sync = Yes

passwd program = /usr/bin/passwd %u
passwd chat = *New*password* %n\n *Retype*new*password* %n\n *password:*all*authentication*tokens*updated*successfully

#Use PAM's password change control flag for Samba. If enables,
#then PAM will be used for password changes when requested by
#an SMB client instead of the program listed in the passwd program.
#It should be possible to enable this without changing your passwd

#chat parameter for most setups.
Pam password change = yes

5. Save the smb.conf file and close it, next run the testparm command to test the smb.conf file for syntax errors. If you have errors go back and fix them and then re-run testparm.

# testparm smb.conf

NSSWICH configuration:

1. Backup your nsswitch.conf file (note that I use the .org which stands for original, I will go back later and make copies of the working files as .bak)

# cp nsswitch.conf

2. After your nsswitch.conf open it and add winbind to the end of the passwd: and group: lines at the beginning of the line. Then save and close the file when you are finished.

passwd: compat winbind
group: compat winbind

3. After you are finished editing the nsswitch.conf file run ldconfig to activate the changes.

# /sbin/ldconfig

Samba Service:

From the console cd over to the etc/rc.d directory , this is where you can view , change or modify your systems services, in the next few steps we will setup these services to ensure they start every time and then we will also start them.

1. From the console use the chkconfig script to see if smb and winbind services are on. We are looking for these services to be on for runlevels 3 and 5.

# chkconfig --list smb

2. If the services are not already set to on for runlevels 3 and 5 turn them on using the chkconfig

Example: (turn on smb and winbind:)

# chkconfig smb on

# chkconfig winbind on

3. Next we will have to disable the nscd service which interferes with the proper functioning of winbind.

#chkconfig nscd off

4. Now turn off the nscd service:


#./nscd stop

5. We are now ready to start smb and winbind, if it is running already restart them:

Example: (note that the two lines are separate commands)


#./smb start

#./winbind start

Join the Domain:

Joining the domain requires that you have name resolution to your password server (PDC) and an administrative account that can move machines into the domain. We will first create the domain account and then we will test winbind and local system accounts and groups to ensure they are both pulling the correct information.

1. From the console as root join the domain the syntax format is explained below:

DOMAIN = the name of your domain (upper case)

PDC = Full name of your PDC server

user_name = The domain username with admin privileges

# smbpasswd -j DOMAIN -r PDC -U user_name

2. We will now test winbind to ensure we can pull user and group into from the domain. Users should show up as DOMAIN+USER when the results are returned.

Example: (get users)
# wbinfo -u

Example: (get groups)
# wbinfo -g

Example: (tests connection)
# wbinfo -t

3. Next test the Linux system password, by changing the nsswitch.conf file the system should now see domain resources along with the local Linux machine accounts (note sometimes this command takes a long time to return)

Example: (list of users)
# getent passwd

Example: (list groups)
#getent group

PAM configuration:


Were almost finished, the pam configuration is the last major component to configure. In this section we will setup the pam files to allow login to the system and we will also setup the base home directory. It would be wise to create a boot disk at this point, the installation CD can also serve as a point of rescue as well just make note of your hard devices listed in your fstab file, trying to find this info later can be hard if you are locked out of your system.

1. The first step will be to backup the pam files we will be working with, in this document there are only three files that will be edited. The pam files are stored in the etc/pam.d , you should be logged on as root, backup the following files, login, samba, and xdm

# cp login
#cp samba
#cp xdm

2. Edit the login file to add your winbind info below is an example of the file I created, remember the order of the lines matters, pam reads the file from the top down allowing you to go on to the next line only if the credentials supplied are good to pass the current line. Lines using and were added.

auth required
auth required
auth sufficient nullok
auth sufficient use_first_pass
auth required
auth required
account sufficient
account required
password required nullok
password required nullok use_first_pass use_authtok
session required skel=/etc/skel/ umask=0022
session sufficient none # debug or trace
session sufficient

3. Edit the xdm file and add the parameters below is an example of my file.

auth sufficient
auth sufficient use_first_pass nullok #set_secrpc
account sufficient
account required
password required #strict=false
session required debug # trace or none
session required
session required

4. Next edit the samba file and ensure it looks like the following example below.

auth required
account required

Create domain home root directory:

Remember in the samba file we specified, template homedir = /home/%D/%U this means that we will have to create the %D (domain) directory and the %U (user) will be created automatically when the user logs on.

Example: (change MyDomain to the name of your domain.)

# cd /home
# mkdir MyDomain
# chmod 777 MyDomain

So now when a user logs in MyDomain+FRED the samba script will put the user in
/home/MyDomain/ and will automatically create FRED's home directory.

Testing PAM Settings:

The following steps are required before you move on if you are not able to perform all the steps below you must correct your pam configuration files so you can. If you get stuck on any of the steps ensure you do not reboot your machine without restoring your original pam files.

Console Login Test:

1. Using Ctrl+ALT+F1 start a new console session we will use this as a back door for testing our PAM setting. At the login prompt test your login using the local root account.

2. After you have verified that you can login using the machines local accounts you can test a console login of a domain account, the username is specified as DOMAIN+USER.

X-windows Login Test:

If you successfully managed to login using both the local root account and a domain account the next step is to test X-windows.

1. From the same console session that you performed the previous tests login as root.

2. Using Ctrl+ALT+F1 change back to your windows session

3. Logout of the X-windows session and return to the login window. (note this will take a long time because the login will pull all the domain accounts to add to the list, don't worry about this now we will change the settings later)

4. Test the login using a local machine account then logout after login is compete.

5. Test domain login using username specified as


If all tests were good congratulation's, if your still “work in process” you can save your pam files with the work you have done to this point but remember to restore your originals if you intend to reboot.

X-window login box:

As you seen during the test, our login box pulled all the account names that exist on the domain, this should be fine for a small user base. If you have a large user base and do not wish to display all the user names you can disable this option from within yast2 under system administration ==> login manager , select the users tab and change the show users to “none” .

Changing File and folder ownership from the console:

Changing ownership of files and folders isn't to different from what you would normally do from a console only now you have to specify the user using the domain scheme of DOMAIN+USER, below is an example.

# chown DOMAIN+USER filename

Part II Server Setup in a Domain Environment:

After you have completed the client install and verified everything is working you can setup the server side. The goal is to setup your Linux machine to support the identical scheme for directories and file permissions and shares as a Microsoft server would. To do this your linux machine must have the following configuration or software installed.

-ACL kernel support (using ext2 or ext3 “rieser filesystem”), by default Suse 9 has this option enabled in the kernel. The ACL option will have to be enabled though on the volume you wish to export your Samba shares.

-The above client setup must be enabled in order for Samba to successfully use the domain as a back end for file and folder permissions.

-If not already installed install the acl tools package to allow acl manipulation and querying from the linux side, at the time of this document the current package is acl-2.2.15-23

ALC support:

By default ACL support is already built into the Suse 9.X kernel , as long as your using a filesystem that supports ACL we are in good shape (ext2 and ext3). To enable ACL we will simply edit our /etc/fstab file and add the ACL option to the mount command of the volume where we will be exporting our Samba shares.

1. Using the console login as root using the su command, cd to the /etc directory and make a backup of your fstab file.

# cp fstab fstab.bak

2. Next edit your fstab and add the acl option towards the end of the file.


/def/hda1 / reiserfs defaults, 1 1

/def/hda1 / reiserfs defaults,acl 1 1

3. Save the fstab file and reboot the machine, if you have any problems it more then likely you using a filesystem that does not support ACL.

Samba Configuration:

The samba configuration will take place in two parts, we will first setup our shares on the the linux side and then we will change ownership of the shares to our Microsoft domain accounts from there to setup permissions and access to the shares. You can later adjust the default permission and creation modes on the samba side if you don't like how I have them here but for the sake of sanity use the default setting I use first.

1. Create the directories you would like to use for your Samba exports, after you have created them run a chmod and then chown to your domain account you will be using later to setup the permissions on the domain side.

# mkdir workgroup-files
# chmod 770 workgroup-files
#chown -R DOMAIN+USER workgroup-files

2. Next create a backup of your working smb.conf file then edit it. For your shares using the following format, repeat the format for each share you wish to export.

Example Share:

comment = share
path = /home/share
fstype = NTFS
browseable = Yes
writeable = Yes
acl support = Yes
security mask = 0750
directory mask = 0750
force security mode = 0750
force directory security mode = 0750
directory security mask = 0750

3. After you have setup your shares save the smb.conf file and restart both your smb and winbind services located in /etc/rc.d directory.

# ./smb restart
#./winbind restart

4. From your windows machine (WINNT, WIN2K , or XP) map to your shares using the account you gave ownership to on the Linux side. Once your mapped you can right click on the share itself to define the share defaults for file creation and default permissions. Individual folders can be manipulated as you would normally. Use a few accounts to connect as different users to test your stetting and ensure it works as you intend it to.

ACL from the Linux Side:

A standard ls or dir command will not show you the ACL info from the linux side , you can use the getfacl and the setfacl command to query or manipulate ACL information from the console.

# getfacl DirectoryName