PCLinuxOS New User Guide : PCLinuxSamba093

HomePage :: PCLinuxOS Forum | Index | Categories | Changes | Login/Register

Using PCLinuxOS 0.93a in a Windows Network

Back to Advanced Topics

Go to PCLinuxSamba if you are running PCLinuxOS 0.93 or below

THIS PAGE MOVED TO http://docs.mypclinuxos.com/PCLinuxSamba093

Introduction


This wiki entry was written to help users of PCLinuxOS 0.93a share files with Windows computers. The Linux project that makes this possible is called Samba and so the software you must set up to share files is called a Samba server. The PCLinuxOS Control Center provides several graphical tools to configure your computer to share files on a Windows network. I've limited this page to discussing the configuration options that are available in the control center. These options should cover the needs of most home and small office users.

Background Information and Terminology

Microsoft's file sharing system protocol is often referred to as SMB/CIFS. SMB stands for Server Message Block and is the original core protocol of the system. Over the years, Microsoft added more features to SMB and in 1996 started calling their file sharing protocol "Common Internet File System" or CIFS. SMB/CIFS provided a way for applications to share data and a means of user authentication. SMB/CIFS runs on top of another protocol called NetBIOS. NetBIOS provides a way for the computers on a network to identify, browse and establish connections with each other. This is why the name of a computer on a Windows network is often referred to as its NetBIOS name. NetBIOS in turn, runs on top of a basic transport network protocol such as TCP/IP, IPX/SPX, or NetBEUI. Almost all computer networks now use TCP/IP. When setting up your Windows computers, it is best to bind only one of the transport protocols to your network interface, otherwise, you may have problems browsing the network according to the Official Samba How To. Don't be discouraged by the length of the "Official Samba How To" as we will be using graphical dialog boxes to set everything up. In most cases, you will not need to read the Samba documentation at all. However, if you need help configuring your Windows computers, an excellent guide has been provided by the Samba project as part of their documentation.
I don't want to overwhelm users with technical details. However, there are some rather technical pieces of information that may be helpful to certain readers. These details wil be placed in boxes on the right side of the page, as you see to the right of this paragraph. Nothing in these boxes is required to get the Samba server configured and working under normal circumstances, so if you want to just skip them you may.

Accessing Shared Folders from PCLinuxOS


The Windows file sharing protocol is a client / server system. This means that some computers act as servers by making shared files available on the network, and there are programs that act as clients by requesting information from the servers. This means that if you only want to use PCLinuxOS to access files that have been shared from other computers, you do not need to set up the Samba Server software on your PCLinuxOS computer. You simply need to use one of the client programs listed below to access the shared folders.

Installing Samba Server


Before you can begin to share files from your PCLinuxOS system, the Samba server software must be installed using Synaptic software manager. If you need help using Synaptic, see the wiki page on Installing Software for screen shots and detailed instructions.

Check Firewall and Host Name Settings

Configuring Other Firewalls
If you are using a firewall other than that provided in the PCLinuxOS Control Center, you must allow the following traffic into your computer from your local network.
Note: This applies only to the firewall running on the interface that connects your computer to the local network. You should NOT open these ports on a firewall that stands between your network and the internet.

If you are running a firewall on the interface of your PCLinuxOS computer that connects to your local network, it must be told to allow incoming request through to the Samba server. The instructions below assume that you are using the firewall utility that is available in the PCLinuxOS Control Center. You may skip this step if you are not running a firewall or if you are running the firewall on an interface that is used for internet traffic only and not your local network traffic. If you are using a different firewall program, see the box on the right.

Now, you need to make sure that your computer has been given a host name. In a Windows network, all computers are identified by their name, which is known as a NetBIOS name. By default, Samba uses the host name of the computer as its NetBIOS name. To check your computers host name, complete the following steps.

Initial Configuration of Samba Server

It's Not Magic, It's A Text File
The configuration settings you enter here, and the settings you enter when sharing folders, are all stored in a well commented text file at /etc/samba/smb.conf . Those who are curious can safely look at it with a text editor since it can only be changed by root. Running the command testparm -s in a console window lets you see how Samba is interpreting the configuration file. To view the default settings in addition to the ones mentioned in the configuration file, run the command testparm -sv in a console window. These commands are useful for advanced users who have manually edited the configuration file and want to check it for errors.

This step creates the configuration file for the Samba server after asking you to enter a few settings.

Now you need to tell the system to start the Samba server at boot.

Congratulations, you now have Samba server running on your PCLinuxOS computer.

Sharing Folders with Guest Access


This section describes how to share a folder so that anyone can access the files in it, (the term folder refers to a directory containing files on your disk drive). There are three examples below that show how to share files in different circumstances.

Sharing a Folder in /var


The /var directory is generally used to store system log files and other data that is generated or used by the operating system. However, some people choose to create a directory in /var to store archives or other data. Even if you don't intend to create a shared folder in /var, I encourage you to follow these instructions and read the explanation below so you better understand how Samba interacts with the file system permissions on your computer. This will help you have success creating shares in your /home directory later on.

First you must create the directory that you will share.

Now you will share your new folder on your Windows network.
Congratulations, any user should now be able to browse to this folder from other computers on your network.

Understanding Samba Shares and File Permissions


The following five exercises demonstrate how file permissions affect whether others can access your shared files and what they are allowed to do. If you wish, try each exercise using the folder you just shared.
  1. Create a text folder as a local user on your PCLinuxOS computer and save it to /var/shared_docs. Browse to the file using Konqueror and right-click on it, select "Properties" and look at the permissions tab. "Other" should have read access only. Now try to access it from a different computer. You should be able to read it, but if you modify it and try to save it you will get "Permission denied"
  2. Now, using Konqueror, open the "Properties" dialog for the file you created and set the permissions for "Other" to "Forbidden". Try to read it from a remote computer now. You will not be able to open it.
  3. Next, using Konqueror, change the permissions on your file so that "Other" has "Read & Write" ability. Now from a different computer, you should be able to open the document, change it and resave it.
  4. From a different computer on your network, open the shared folder and try to save a new document. You should be able to. Now, on the PCLinuxOS computer, open the "Properties" dialog on the file you created from the other computer, click on the "Permissions" tab and look at the owner and group that the file belongs to. The owner is "nobody" and the group is "nogroup"
  5. Finally, open Konqueror as Super User ( it in the menu at Applications --> File tools --> File Manager - Super User Mode ), and change the permissions on the /var/shared_docs folder so that "Other" has only "Can View Content" permission. Now try to save a new file in the shared directory from a remote computer. You will get permission denied. Next, try opening the file that had "Other can Read & Write" permissions, modify it and then save it without changing the name of the file. You will be able to modify the file. When you are done with this, if you intend to use the /var/shared_docs folder, you may want to change the permissions on the folder back so that "Others can View & Modify".
What Really Happens When Users Connect to Shared Files

Below is brief outline of what samba does when someone on the network requests access to a shared folder. The process listening for the request is called smbd. When a request comes in, Samba examines any user name and password information provided in the request. If the password matches that of a user that Samba knows about (we'll cover this later), then smbd spawns another smbd process that is owned by that user. Otherwise, a check is made so see if the requested share allows guest access, if so, smbd spawns another smbd process with the User ID of "nobody". If no match is found and no guest access is allowed, a permission denied error is sent back over the network.

Once a remote user has been authenticated for access to a shared folder, all the actions he requests are sent to the smbd process that is running with his user ID, as explained above. So if I, as a guest, request to read a file in a shared folder, the request is sent to the smbd process created for me. smbd, which is running as user "nobody", then tries to read the file. This is where the Linux file permissions take effect. The Linux kernel sees the process trying to access a file, and checks whether the file's permissions allow a process running with a User ID of "nobody" to read the file. If it does not, the smbd process is told that access to the share is denied. The smbd process then sends a permission denied error back to the remote user that requested the file. However, if the permissions are such that user "nobody" can read the file, then the smbd process reads the file and transmits the contents to the remote user.

Since the most common problem new Samba users have is unexpected "Access Denied" errors, it is important that you understand why the five exercises above work the way they do before continuing to the next example. When having this problem, many user reason that they have shared the folder, they configured the share to allow "Public" access, so samba should just allow anyone to get to the files in the folder. They think file permissions shouldn't matter. But they do.

Windows provides a file sharing mode where folders are shared without concern for which user is trying to access them, although there is an option to require a password for access to any particular folder. This is called "Share" level security. However, Linux requires everyone who accesses the file system to have a valid User ID and Group ID that can be checked against the permissions on the files. If the user requesting files from the shared folder is known to Samba on your PCLinuxOS computer system, he is allowed on the system with his own user name. However, when guest access is allowed, a User and Group ID must be assigned to unknown users. On our Linux system, guest users are given the User ID of "nobody" and the Group ID of "nogroup" This explains why in the fourth exercise above, we saw that when our remote user created a new file in the shared folder it was owned by "nobody".

The permissions on regular files are easy to understand. In the exercises above, we were accessing all files as user "nobody". We did not have ownership and we weren't in the group that owned the files. So the permissions for others were the ones that affected our access. In the first example "Others" only had read access to the file, so we couldn't write to that file. In the second example, we made it so "Others" had no permissions for that file, and we couldn't even read it. In the third example, we gave "Others" both read and write access to the file, and thus we were able to read the file and alter it from the remote computer.

What Directory Permissions Mean
On regular files, read permission means you can view the contents of the file, write permission means you can modify the contents of the file, and execute means that you can have the operating system run commands in the file. Directories also have read, write and execute permission, but the meaning of these permissions is somewhat different.
A directory will never have read or write permissions without having execute permission. Read by itself only lets you see the names of the files in the directory, but not their attributes, and you will not be able to do anything with the files. Write by itself does nothing at all.

The fifth example demonstrates that the permissions on the shared folder affects the ability of remote users to access the files. In order to browse to a file, a user must have "execute" permissions on every directory in the path to the file. (To see the actual read, write, and execute permissions in Konqueror, you must click on the 'Advanced' button on the "Permissions" tab of the file properties dialog box.) So if I shared a file at /home/hankcurt/music/shared_music/file.mp3, in order for a guest to read the file.mp3, "Others" need to have execute permission on /home, /home/hankcurt, /home/hankcurt/music, and /home/hankcurt/music/shared_music. If the execute permission is not set on any of those directories, I would get a permission denied error when I tried to enter the shared_music folder. Finally, as was demonstrated above in the fifth exercise, if we take the "write" permission off of the shared folder, a remote user can still alter a file that already exists in that folder, provided they have write permission on the file itself. However, they are not allowed to create new files or delete existing files. ( See the box at the right for a further explanation of how directory permissions work.)

Sharing a folder in /home with Guest Access


Often there is data on your computer that you want all local and network users to be able to access. For instance, I have a large number of music files that I want everyone to be able to play. It would be logical to create a shared folder called shared_music in the /home directory, change the permissions so everyone has access, and then use Samba to share it on my local network. If I set this up, it will work fine for a few minutes, and then suddenly everyone starts getting "Access Denied" errors. When I check out the file permissions on /home/shared_music, I find that "Others" no longer have any permissions set. What happened?

The answer is that a security monitoring program called msec is doing its job. This program checks the permissions on certain files once an hour, and resets them if they have changed. By default, everything in the /home directory is reset so that "Owner" has all permissions, "Group" has read and execute permission, and "Others" have no permissions. We could disable msec, but that is not a good option because it does perform other functions that enhance the security of the operating system. Fortunately, there is a program called drakperm that we can use to tell msec that we want permissions set a certain way on specific directories. To see how this works, follow the steps below for setting up the /home/shared_music folder.


The next step is to tell msec how the permissions on our /home/shared_music folder are to be set.

Now we can manually run msec to make sure it is setting the permissions on the shared folder the way we expect.

Users on your local network should now be able to browse to the "Music_Box" folder and access files that are in /home/shared_music on your PCLinuxOS computer.

Sharing a Folder That is Inside Your Home Folder


Some people like to provide each user with a shared folder that is inside their own home folder. This allows users a convenient way to make documents available on the local network. For instance, in my case, I would create a folder at /home/hankcurt/network_shared where I could drop my documents so that others on the network could read them.

The guest user will be given the User ID of "nobody" and Group ID of "nogroup". So for the guest user to have access to the network_shared folder, both the /home folder and the /home/hankcurt folder must have execute permission set for "Others". However, msec is setting the permissions on the /home/hankcurt folder so that the "User" has all permissions, the "Group" has read and execute permission, and "Others" have no permissions. Thus a guest user will never be able to get access to the shared folder. We could solve the problem by telling msec that we want "Others" to have execute permission on /home/hankcurt, as we did in the previous section, but this causes another problem. If "Others" have execute permission on my personal folder, any local user can get into my personal folder and read or modify files. I don't want that.

There is a better solution. The "Group" ownership for every user's home folder is set to a group with the same name as the user who owns the folder. My user name is hankcurt and so my personal folder "Group" ownership is set to the group hankcurt. Since the "Group" permissions on my home folder are read and execute, anyone who is in the 'hankcurt' group could enter my home folder. I am the only person on the computer who is in the group 'hankcurt'. That keeps everyone else out of my personal folder. But, if I tell Samba that guest users who access my folder should be added to the 'hankcurt' group while they are connected, then they could enter my home folder and gain access to the network_shared folder without allowing everyone else access to my personal files. The steps below show how to set this up.

First, create the folder that will be shared.

Next share the folder on the network.

Others on the network will now be able to read files from the shared folder inside the user's home folder. If you chose to allow the remote user to create files, the files will be owned by "nobody" but the group ownership will be that of the user whose folder they are accessing. In my case a file created by a remote user would have Group ownership of "hankcurt".

How to Access Shared Folders With Your Own User ID


In the previous sections, we always assumed that Samba would not know who the remote user was, and thus would try to grant guest access to the shared folders. If the remote user has a user account on the PCLinuxOS machine, it is possible for Samba to recognize his user name and password and then grant him access to shared folders under his normal User ID, just as if he were logged onto the machine locally. There is extra incentive to configure this because the remote user will also be able to access his entire home folder, thanks to a special share definition called "Homes" that was created automatically when you first installed Samba.

To inform Samba that you are a user on the system, follow the steps below.
Why Samba Needs User Names and Passwords Re-entered

All of the user names and passwords have already been entered in the system when the user's accounts were set up, so you may wonder why must they be entered again for Samba. The answer has to do with how the passwords are stored. No modern operating system stores user passwords as plain text. Usually, the passwords are encrypted using an algorithm that can not be easily unencrypted and then the result of the encryption is stored. Then when someone enters a password to log on to the system, the password they enter is encrypted using the same algorithm and then is compared with the encrypted password that has been stored. If the two encrypted forms of the password match, the user is authenticated.

A problem arises because Linux stores passwords using one encryption method but the Windows network clients send passwords that are encrypted by an entirely different method. There is no way to compare the two passwords because they are encrypted differently. Since the passwords that have already been entered for use by Linux cannot be unencrypted, Samba requires that you re-enter the passwords in plain text. Then Samba will store the passwords using an encryption method that is compatible with the encryption used by the Windows network clients.


Now you probably want to see what you have gained by adding users to Samba. If you use the same user name and password on a remote computer on your network, you will be able to access your user's home directory. Your home directory may not show up when you browse the shares on the computer, but if you type \\hostname\username in Windows explorer or smb://hostname/username in Konqueror ( where "hostname" is the name of the computer and "username" is the user's name on that computer ), you should be allowed in to your home directory.

Also, you no longer have to allow guest access on folders you share on the network unless you want to. Just set the "Public" setting to "no" when configuring the shared folder in the PCLinuxOS Control Center and only users that have been added to Samba will be able to access the share. Or you can set the permissions on shared files so that guests can only read the files but authorized users can modify them. A user's group memberships also apply when that user access a shared folder over the network, so group ownership and permissions on the files can be used to allow access for one group of users while denying access to others. When a user that has been added to Samba creates files in a shared folder, those files will be owned by that user and have their group ownership set to that user's primary group.

Summary of Share Configuration Options


Not every samba configuration option available in the PCLinuxOS Control Center was covered in the text above. This summary will briefly explain all of the options that can be used to modify how a folder is shared on the network. These options are in the dialog box titled DrakSamba entry. You can get to this dialog box by following the steps below:

This screen shot has been annotated with numbers to identify each section of the box to make it easy to find the description in the list below.
image

(1) Basic Samba Share Configuration


This is the basic portion of the configuration window that is always visible.

(2) User Options - Samba user access


These options are not visible unless the "User Options" label is clicked. According to the documentation for Samba 3.0 and later, the 'Read List', 'Write List', and 'Admin users' options are not valid when using share level security. PCLinuxOS uses share level security by default, so the first three options listed here will not work unless you change the "security = SHARE" line in the /etc/smb.conf file to "security = USER". The options in the section all take a space separated list of user names as entries. The user names entered here must also be added to Samba as described in the section above entitled "How to Access Shared Folders With Your Own User ID".

(3) Mask Options


These options are not visible unless the "User Options" label is clicked and the dialog box expands to display them. The configuration options in this section will affect the permissions and group ownership of files that are created in the shared folder by a remote user.
Numeric Representation of Permissions

The permissions for files and directories are primarily composed of either allowing or denying read, write and execute permission for each of three groups; user, group and others. There is a system that makes it easy to represent the permissions on a file with a four digit number like this 0764. This box will explain how to interpret these numbers.

The first of the four numbers represents special types of permissions that we don't have space to discuss here. Most of the time, this number will be zero, meaning that none of these special permissions is set. The second number represents the permissions for the user who owns the file. The third number represents the permissions for the group that owns the file. The fourth number represents the permissions for others.

To generate the numbers from the permissions, each permission is given a value and then the values are summed

So in our example, 0764, we can decipher what permissions each category of users has


(4) Display Options


These options control whether certain files are displayed when clients browse the shared folder. Also, since Windows is generally case insensitive ( treats upper and lower case letters as equivalent in file names ) while Linux is case sensitive, there are options to control how capitalization is to be handled when a client creates a new file.

There are 3 comments on this page. [Display comments]

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by Wikka Wakka Wiki 1.1.6.2
Page was generated in 0.3443 seconds