4. General ConceptsMost Unix users are familiar with NFS for sharing files in the network. Although CIFS serves the same purpose as NFS, there are some subtile differences. This chapter is dedicated to those differences.
The situation is different with CIFS. The clients have to prove to the server that a file access comes in fact from a particular user. This proof is carried out by logging in each user at the server with username and password (the credentials) [unless your server is in share-level security mode, see later]. A malicious client can only gain access with the privileges of a user who's credentials it knows.
The difference for the user is that he or she has to provide credentials before doing any access. If you run the Sharity GUI application, this task is made more transparent for you: Whenever you access a server where you are not already logged in, a panel pops up asking you for your remote username and password. These credentials are then used to log you in at the server. If you don't run the GUI, you have to use the commandline tool cifslogin before accessing data. This is how to tell Sharity about your credentials if it has no way to ask. By the way: The user who mounted the share is automatically logged in during the mount. It's worth noting that you can login as any user you like on the server (e.g. Administrator), as long as you know the appropriate username and password.
Sharity has to perform a useful mapping between the Unix and the CIFS file attributes. The mapping is as follows:
Owner: All files belong the the user who accesses them. This is necessary because Unix allows only the owner of a file to change attributes.
Group: The group of all files is the default group of the accessing user.
Permissions for Owner: The read permission is always on and the write permission is taken from the read-only DOS file attribute. The execute permission can be mapped to any remaining DOS file attribute in the configuration.
Permissions for Group and Others: These permissions are copied from the owner's permissions. The access permissions have no meaning security-wise. The security check is performed by the server based on the accessing user's credentials.
File Modification Time: This time has a direct correspondence in CIFS, although the granularity of the time scale depends on the CIFS subdialect negotiated with the server. It's likely that times can be stored in two second resolution only.
File Read Time: Not all CIFS dialects provide this attribute. If it's not available, the modification time is substituted instead.
Last Inode Change Time: There's no such thing as an inode in CIFS and hence no such attribute. Sharity substitutes the file creation time, if it is available or the modification time otherwise.
CIFS has no equivalent for Unix specialities like symbolic links, hard links, Unix domain sockets, device files etc. These things can't be created in a Sharity mounted directory. However, since symbolic links are so important in a Unix environment, Sharity can fake them. This feature is off by default and can be enabled in the configuration. Faked symbolic links are stored as ordinary files on the server containing a magic number and the path where the link points. These files differ from ordinary files in their DOS attributes: They have the system- and the hidden-attribute set and must not be read-only.
The browsing facility is represented by a Browser in Sharity. You can mount a browser in the same way as you can mount a remote file share. Below the browser mountpoint is a two-level deep hierarchy of server names and share names. Once you get to the share name, Sharity automatically mounts the share at a private place and redirects you to this new mountpoint by means of a symbolic link.
Browsing is a very nice feature, but it must be set up correctly in order to work. This is not always easy and we will therefore explain how browsing works. The first thing a client has to do is to get the list of file servers. This list can be obtained from a Browse Server. There's at least one Browse Server for each workgroup or domain. There must also be at least one Browse Server in each network segment. A network segment (or broadcast area) consists of all machines which can be reached without going through a router. Sharity needs to know the Local Master Browser. This is the Browse Server in Sharity's network segment. It can be found by broadcasting a Netbios name lookup for the domain or workgroup name. Once we know the Local Master Browser, we can ask it for the list of file servers, look up the IP addresses for these servers by means of the Netbios Name Service and then ask these file servers for their list of exported shares.
From the above explanation you can see that browsing depends on
Each Windows machine can become a Browse Server, if required. You don't have to worry about the Browse Server if there are Windows machines in your network segment which are always up and running. If you can't guarantee this, e.g. if you have separated network segments for Unix and Windows, you need a CIFS server on at least one Unix machine which can provide the Browsing Service. Samba beginning with version 1.9.17 can do this. It may therefore be necessary to install Samba on at least one Unix machine in every network segment to make browsing work. You allow Samba to become the Local Master Browser by setting
local master = yesin the configuration file smb.conf. For more information about browsing, please read the (more technical) documentation distributed with Samba in the file:
docs/textdocs/BROWSING.txtor the more user-friendly overview in
Sharity Manual 2.9 Beta 7 | Copyright (C) 2004 OBJECTIVE DEVELOPMENT Software GmbH | http://www.obdev.at/