Sharity Context Help

Help Mode
You have clicked the help button and are therefore now in help mode. You can go back to normal mode by clicking help again or by closing the help window.

How to get Help
If you move the mouse cursor over a component with help associated, it will turn into a question mark. Clicking on the component displays the help text in this window. Expert Mode
Many things can be configured in Sharity. Some things are obvious, some less obvious or even dangerous to change. To protect you from serious mistakes and to show you what's intended to be changed and what not, the following distinction is made:

Things you will probably want to customize can simply be changed in the user interface. You have to be root for most settings unless you have allowed all users to change settings in the "Global" section.
Things you probably don't need to customize are grayed out and are not editable by default. These settings can only be edited after you have declared yourself an "expert" by means of the the Expert Mode switch.
A third category of settings is not even available from the GUI. These things can only be changed by editing the configuration file. You definitely don't want to change these. Add
With the Add button you can add an explicitly configured item to the list. You don't need to add an item explicitly unless you want a configuration different from the default. The default for not configured items are taken from the .default entry. Delete
This button deletes a configured item from the configuration database. If the item is part of the factory settings in the configuration file, it can not be removed, but the settings return to their factory defaults. Table of Mounts, Column Mountpoint
The table of mounts displays all currently mounted objects. The Mountpoint column displays where the mounted object is available in the filesystem. Table of Mounts, Column Owner
The table of mounts displays all currently mounted objects. The Owner column tells you who established a mount. This information is important because only the owner of a mount can manipulate it (such as unmount it, store it or delete the stored information). Table of Mounts, Column Module
The table of mounts displays all currently mounted objects. The Module column tells you which module is responsible for the data you find under the mountpoint. Various modules may provide different functionality. The cifsFile module allows you to access files from a remote CIFS server whereas the cifsBrowse module is an automounter displaying all available file server resources in a Windows network. Table of Mounts, Column Mounted Object
The table of mounts displays all currently mounted objects. The Mounted Object column tells you what is actually mounted under the mountpoint. The interpretation of this string depends very much on the module responsible for the mount. For the cifsFile module, the string displays the Windows representation of the mounted share and for the cifsBrowse module it is simply the name given to a particular browser configuration. Table of Mounts, Column State
The table of mounts displays all currently mounted objects. The State column displays the mount's properties (stored, mounted etc.). Each property is represented by a character:
M ... Mounted
A ... Automounted by Browser
R ... Read-Only
S ... Stored Mount...
This button brings up the mount dialog. For more information, click the button and query the help entries of the mount dialog. Unmount
Clicking this button will unmount the selected mountpoint. If unmounting does not succeed, an appropriate error is displayed. You must be the owner of the mount or root in order to unmount. Store
Clicking this button stores the mount in the database. All stored mounts are automatically re-established at startup of the Sharity daemon. You must be the owner of the mount or root in order to store it. Delete Stored
By clicking this button you remove a stored mount from the database. It will not be re-established after the next startup of the daemon. Mountpoint
Specify the mountpoint of the object here. The mountpoint must be a directory and it must exist before the mount is attempted. You must also be owner of the mountpoint or root. Frontend Module
The frontend module is the actual mechanism how the files are brought into your filesystem. Sharity comes with at least the NFS2 frontend which should work on all Unix machines. Use this module, if you are in doubt. Mounted Object
The interpretation of this string depends on the backend module you use. For the cifsFile module you can simply type the name of a Windows share here (e.g. //server/share or \\server\share). For the cifsBrowse module it's the name of the browser configuration. Backend Module
The backend module provides the data displayed under the mountpoint. It determines the kind of service you will get and thereby defines the interpretation of the string passed in Mounted Object. Mount read-only
If this flag is on, the mount is done in read-only mode (no changes to the mounted data are possible). Use this flag if you want to be sure that nobody can modify the data. Cancel
Click this button if you decided otherwise and don't want to mount anything now. OK
Click this button to establish the mount you have set up in the panel. Server Side Character Map
Sharity works with the Unicode 16 bit character set internally. If it can negotiate Unicode filenames with the server (e.g. Windows NT), this configuration variable is not used. Otherwise this file defines the mapping from Unicode to an 8 bit encoding. This must be the same encoding the server uses. The default encoding on Windows machines is Codepage 437 in the USA. Sharity comes with several encoding tables such as the DOS codepages and various Asian mappings. Client Side Character Map
This configuration is similar to the Server Side Character Map, but it defines the mapping used on the local machine (the client). NFS (the default frontend module) can't do Unicode, only various 8 bit encodings. You therefore always need to specify the correct mapping table here. Most Unix operating systems use ISO 8859 mappings (at least in Europe and the USA), MacOS X uses UTF-8, but you may also select ShiftJIS, EUC or other Asian mappings. Users may change Configuration
By default, only root can change Sharity's configuration. This may be uncomfortable on a single user machine where you don't always want to become root just to change a setting. Especially on MacOS X you would have to start the GUI application from a Terminal window using sudo. To make things easier, you can allow all users to change configurations by setting this switch to on. Do it only if you trust all users who have access (physical or login) to your computer. Users may store Passwords and Mounts
This setting allows you to disable storing of passwords and mounts for ordinary users. You should not allow storing of passwords and mounts if storing passwords is not safe (see the security notes in the online help for the Store button in the login list) and if you can't trust all users to understand the security implications. Defaults
This button sets all configuration options to their factory settings. Revert
This button reverts all configuration options to their stored values. Use it if you have changed something and don't want the changes to take effect. OK
This button activates and stores your changed configuration options. NFS Retries
Together with NFS Initial Timeout this setting defines the timing behaviour of the NFS interface used internally by Sharity. See the help item for NFS Initial Timeout for more information. A value of -1 means "retry forever". NFS Initial Timeout
This setting is used if you use the NFS2 frontend module for mounting. The value for the NFS timeout has been carefully chosen, but if you have good reasons to change it, you can do it here. Please note that the configured value is only the initial timeout, not the total timeout. After the first timeout period the request is retried and the timeout period is increased (usually doubled, up to a limit) on each failed retry. The total timeout is determined by this value in conjunction with the number of retries. NFS Kernel Attribute Cache Time
This value determines for how long the operating system kernel may cache file attributes before it must ask Sharity again. Since Sharity implements its own caching, you can keep this value at zero.
Security Note: A value greater than zero is a potential security risk on a multi-user machine. Due to the mapping from DOS to Unix attributes, Sharity always returns the same permissions for user, group and other. If the kernel caches these attributes, it may base access control decisions on that value. It may thus return data cached for one user to an other user, without asking Sharity. This other user can get access to the cached data during the caching time without ever logging in to the server. If it is possible that multiple users are logged in on the computer where Sharity runs and if these users don't trust each other, always leave the caching time at zero!
Performance Note: On some platforms, the caching time for attributes can have a considerable effect on the write performance. Good write performance depends on an undisturbed pipeline of write commands. However, if the kernel is not allowed to cache attributes, it interrupts the write pipeline every few 100 milliseconds for an attribute read. Even if the attributes are cached in Sharity, the breaking of the write pipeline may degrade write performance. NFS File-Handle Lookup Strategy
This is a setting for the NFS2 frontend. NFS relies on unique and for ever constant NFS file identifiers, which can not be provided by all backends. Sharity therefore has to manage these identifiers itself. There are currently two strategies for assignment of NFS file identifiers to files: the Table and the Pseudo-Inodes.

The table-strategy is a strictly correct implementation, but it may need quite a bit of memory if you access a lot of files. As a rough estimate, it has to store 20 bytes plus the size of the filename for every file accessed. If you do a find over a large server, you can easily use up a couple of megabytes. This memory goes primarily on the account the swap file or swap partition.

The pseudo-inode strategy is a statistical approach and can't guarantee correct lookup (although the probability for failure is very low) and it can't provide full Unix semantics for file renaming (Unix requires that a file's inode number does not change on rename or move; that can't be provided by this strategy). For the price of these disadvantages the memory consumption does not depend on the number of files accessed. It's not recommended to use the pseudo-inode strategy unless you have very good reasons to do so. Browser's Domain
A browser lists the hosts (and their shares) in a given domain. The term domain in this context means domains in the sense of Microsoft's workgroups, not internet Domain Name Service (DNS) domains. This value defines the domain the browser will show. If it's left blank, it defaults to the client's default domain configured in the "CIFS General" section. Automount Path
The automatic mounting of shares by the browser works in the same way as NFS automounters do: The shares in the browser are symbolic links (aliases). If these links are resolved by accessing them, the share is mounted at a private place and the link points to that place. This mechanism requires a private place where shares can be automatically mounted. This private place, the automount path, is configured here. Auto-Unmount Timeout
The browser's automounter will mount every share that is accessed. Shares will be automatically unmounted after a certain time of inactivity. The inactivity timeout is configured here. Enable Auto-Unmount
This setting selects whether automounted shares will be unmounted automatically after the configured timeout. On some platforms (e.g. Mac OS X) it may be useful to disable automatic unmounting because applications don't cooperate with the automounter. Show List of Domains
Sharity can show an entry Entire_Network in the browse list for a domain. This entry will list all domains known to the local master browse server. If you don't want such an entry, set this switch to off. Show Admin Shares
Windows machines export a lot of shares by default which are not listed in other Windows machine's browse lists. These shares are used for administrative purposes. You usually don't want to list them with Sharity, too. If you want to see these shares, set this switch to on. Add explicitly configured Servers
If you activate this setting, all servers configured in the CIFS Servers section will be added to the browse list, regardless whether they are in the workgroup or not. It may be useful to add remote servers to your browse list. List mounted Servers only
One some platforms, the GUI file manager does not work well with Sharity's automounting and browsing facility. The file manager on these platforms does some look-ahead: If it finds a directory, it looks at its contents even before the user selects the directory for viewing. Sharity, on the other hand, interprets the access as a desire to log in to the server. If you select the browse folder (e.g. /CIFS) on one of these platforms, you will be confronted with a bunch of login panels, one for each server in the net. This is annoying, of course, especially if you have many servers.

Unfortunately there's nothing Sharity can do to prevent the file manager from accessing the directory's contents in advance, except not listing the contents of the browsing directories. This is what this option does: If you activate List mounted Servers only, Sharity will not list anything in the browse directory. You may think that this makes the browser useless. Browsing is its main purpose, after all. And you are right, it makes browsing impossible. But it still retains the functionality of automounting. The server- and share-directories are actually there, only they are not listed. If you access a share by name, the access will succeed and the accessed resource will be automounted. As long as a resource is automounted, it is also listed in directory listings.

You may thus use the automounter by placing a symbolic link at some place, e.g. your home directory. This symbolic link points to the network resource in the browse directory (e.g. /CIFS/Server/Myshare). If you change directory to this link or access something through the link, server and share are accessed by name in the browse directory and are therefore automounted. This is, by the way, how most NFS automounters work. Mount With Frontend
Since automounting works automatically, you can't provide any mount options during mouning. You must therefore specify them here for the browser. This option defines the frontend module which will be used for automounted shares. For reasons which are beyond the scope of this help text, this entry is not a popup list, you have to type the module's name by hand. If you want to see a list of available frontend modules, go the the list of mounts and click the Mount... button. The current version of Sharity ships with nfs2 as the only frontend module, so there is no choice anyway. Defaults
This button sets all configuration options to their factory settings. Revert
This button reverts all configuration options to their stored values. Use it if you have changed something and don't want the changes to take effect. OK
This button activates and stores your changed configuration options. Default Domain
Here you define the domain or workgroup your computer belongs to. This is not the domain the browser will show (the browser's domain can be configured in the CIFS Browsers section). It is the domain sent to the server for identification of the client.
Don't confuse the term domain with domains of the internet Domain Name Service (DNS). As far as Sharity is concerned, domains and workgroups are the same thing. WINS Server
Sharity can translate computer names to internet addresses by means of Netbios Nameservers, called WINS servers by Microsoft. If your network is configured to use a WINS server for Netbios name resolution, you should enter its internet address here. If in doubt, you might get away with setting the address to 255.255.255.255, the broadcast address. If your network does not use a WINS server, leave this field blank. Scope-ID
Netbios, the underlying protocol of CIFS, supports the concept of scopes. Members of different scopes can't "see" each other. If your network is configured to use a scope-ID, you must enter it here.
Using Netbios scopes is strongly discouraged. Netbios NS Initial Timeout
This is the time Sharity waits for a reply from the WINS server (used for Netbios hostname resolution) before it retries a request. The actual request timeout is doubled after each retry. Netbios NS Maximum Timeout
If Sharity has not received a reply from the WINS server after this amount of time, the Netbios nameserver request aborts with an error and resolving via DNS is tried (unless it is disabled in the configuration, of course). Enable Netbios Name Lookups
This setting, together with Enable DNS Name Lookups, determines how hostnames are resolved to internet addresses. The following operations are performed:
1. Look up the host name in the CIFS Servers configuration. If an IP address is explicitly configured there, it is used.
2. Do a Netbios name lookup, if enabled.
3. Do a DNS lookup, if enabled.
The first method which succeeds determines the internet address used. Enable DNS Name Lookups
This setting, together with Enable Netbios Name Lookups, determines how hostnames are resolved to internet addresses. The following operations are performed:
1. Look up the host name in the CIFS Servers configuration. If an IP address is explicitly configured there, it is used.
2. Do a Netbios name lookup, if enabled.
3. Do a DNS lookup, if enabled.
The first method which succeeds determines the internet address used. Connect on Port
CIFS uses port 139 (the Netbios session service port) for connections. Don't change this value unless you know for sure that the server uses a different port (e.g. server accessed through proxy or a SSL CIFS server). Server's IP Address
You usually don't need to supply the server's internet address here because it can be determined by name lookups from the server's name (Netbios lookup, DNS lookup or both). If your server can not be resolved by any of these methods or if the resolved address is wrong, you can override it here. The format is a dotted quad (e.g. 12.34.56.78). Server's Security Mode
You probably don't want to change this setting. The server usually tells Sharity whether it is in share-level or user-level security mode. However, if you use certain (tricky) configuration options in Samba, it reports the wrong security mode. In this case you can override the value provided by the server with this setting. CIFS Connect Timeout
This value sets the timeout used during connection attempts to servers. If the server is down, you have to wait this amount of time until you get an error response. On the other hand, if the server is up, it must respond within this interval. CIFS Request Timeout
This is the timeout used after a connection to the server has been established and the server is therefore know (or better: expected) to be up. It should be much longer than the CIFS Connect Timeout to allow retries of the underlying TCP network protocol. If the server goes down, Sharity will wait this amount of time until an error is returned. You may have to increase the value if you mount a server over internet with a slow link and high packet loss. Watch out for timeout errors in the syslog!"; Remote Guest User Name
If you define a guest user, users are not asked for passwords but rather logged in automatically as this user at the server. This may be useful if you have a server with a public share and all Unix users should be able to access the share without further actions (such as logging in at the server). Guest User's Password
If you define a guest user in Remote Guest User Name, you must also provide the user's password (for the server) here. The password is stored and displayed in clear text. Take Execute Permission from
CIFS is based on DOS file attributes, which consist of the flags Archive, Hidden, System and Read-Only. The Read-Only flag is always mapped to the Unix write permission. The Unix read permission is always on and this setting configures what happens to the Unix execute permission. You can map it to any of the remaining DOS file attributes or switch it permanently on or off. Invert Execute Permission
The Unix execute permission is taken from the DOS file attribute defined with Take Execute Permission from. This setting allows you to invert the flag. Case Mapping
Sharity usually preserves the case of filenames received from the server. This may be inconvenient, e.g. if on a DOS server all files are in uppercase. This setting allows you to map filenames to all uppercase, all lowercase or leave them as they are. Enable faked Symbolic links
Unix has provision for symbolic links (aliases) in the filesystem. This feature is missing on Windows and hence CIFS. Sharity can therefore not provide symbolic links directly. However, if you rely on this feature, Sharity can fake symbolic links as files with special file attributes on the server. This does not make them symbolic links for the server, but all Sharity clients will correctly interpret them as symbolic links. Faked symbolic link files have the system and hidden attribute set and must not be read-only.
Modifications of this setting become valid only if the server is disconnected. This can be accomplished by restarting the Sharity daemon or rebooting the machine. (For servers other than the LMB, it's sufficient to log out all users and unmount all shares from the server.) Disable Finder Trash
There is a bug in the Mac OS X Finder or the Carbon framework which may have fatal consequences in combination with Sharity. If you rename files or directories on a remote share and then eject the share and mount it again, Finder may mix up the Trash with a directory. You look into the Trash and see the contents of a data directory. If Finder thinks that one of your data directories is actually the Trash and you empty your Trash, the data directory will be deleted!
To work around this bug, Sharity disables the Trash by default. If you enable it, always eject or unmount all Sharity volumes before you empty the Trash. Alternatively, you can open the Trash and look at the content to verify which files you are going to delete.
The Finder bug is known to exist on all versions of Mac OS X up to 10.1.4. It is very likely that all future 10.1 versions are also affected. The Carbon framework in Mac OS X emulates resource forks for files on non HFS volumes. It uses file names starting with ._ for this purpose. Since these files are annoying in many situations and resource forks are often not needed, you can disable resource forks with this option. Sharity will return an error to the application when it tries to create a resource fork.
Please note that some applications (notably Finder) don't cope gracefully with this error. Finder tries to create resource forks even when copying files which don't originally have resource forks. If the creation of the resource fork fails, it refuses to copy the file contents, too. [Valid for Mac OS X 10.0.3.] Require SSL Encryption
Sharity negotiates encrypted transport over the Secure Socket Layer (SSL) automatically. This may not be desirable as it allows downgrade attacks from the server. By setting this switch to on, you don't allow unencrypted connections to the given server. SSL Protocol
There's more than one version of the SSL protocol around. You can select which version is used (or which versions will be negotiated) with this setting. Bug Compatibility
The SSL standard is defined formally by a specification. In addition to the specification, there's also a reference implementation which has several bugs. If the SSL part should be compatible with the reference implementation's bugs, set this switch to on. Path to accepted Certificate(s)
A connection which is really secure requires not only encryption but also authentication. SSL therefore introduces the concept of certificates. If you don't understand this, please read a good introduction to SSL or at least the short section about certificates in Sharity's manual. This setting defines the Certification Authorities (CA) Sharity will accept. It should point to a PEM encoded file holding the CA's certificate. Require valid Server Certificate
If this flag is off, Sharity will not verify the server's certificate. This is useful if you want to connect to a server certified by an authority you don't trust or whose certificate you don't have. You should be aware, however, that such a connection can not be secure. PEM File with private Key
If your server requires client certificates (which it probably should do for security reasons), you need a constant private key (the key that's certified). The key should be stored in PEM format in a file and this setting should point to the file. PEM File with Certificate
If you use a client certificate, this setting should point to the file holding the certificate in PEM format. Certificate and private key may be stored in the same file. Enter your License Key here
This is the only input field in this dialog. Enter the license key and click OK. The other fields will display the key's properties. The license key will only be accepted if no server is connected. You can achieve this by unmounting all shares and logging out all users. This limitation is necessary because the license key sets limits in terms of connected servers and Sharity could get into an undefined state if setting the license were allowed while servers are connected.

Please note that the License Identifier is not equivalent to the license key itself. It consists only of the first part, which is sufficient to identify the license owner. License Identifier
The license identifier is a kind of unique identifier for a license. It's not sufficient for licensing the program because it does not contain the verifier part. License Type
Licenses are classified depending on who buys it, whether it's a free license etc. (e.g. "Student", "Educational Institution" or "Business"). This field contains the type of your particular license. Max. active Clients
This field gives the number of (Unix) client machines where Sharity may be installed and used with this license. Max. mounted Servers
This field gives the number of servers which may be mounted by the clients. This is NOT the number of mounts or shares: You may mount as many shares as you like from a server and you use still only one server.
Servers are usually counted network wide. This means that if one client mounts server A and an other one mounts server B, this are two servers for the license counter. If all clients mount server A, that's still only one server. Expires
Licenses can have an expiry date (e.g. test or demonstration licenses). If your license expires, this field contains the expiry date in YYYY-MM-DD format. Defaults
This button sets all configuration options to their factory settings. Revert
This button reverts all configuration options to their stored values. Use it if you have changed something and don't want the changes to take effect. OK
This button activates and stores your changed configuration options. Table of Logins, Column Server
The table of logins displays all currently established and all stored logins. The Server column contains the name of the server where the user is logged in. Table of Logins, Column Local User
The table of logins displays all currently established and all stored logins. The Local User column tells you which local (Unix) user is logged in at the server. Table of Logins, Column Remote User
The table of logins displays all currently established and all stored logins. The Remote User column contains the name of the remote user (at the server) which is associated with the local user through the login. Table of Logins, Column Domain
The table of logins displays all currently established and all stored logins. The Domain column contains the domain name sent to the server during login. This is usually the client's default domain. However, some servers accept connects only from clients in their own domain. If you want to connect to a server in an other domain, you may have to provide a different domain. Table of Logins, Column State
The table of logins displays all currently established and all stored logins. The State column shows the login's properties (stored, established etc.). Each property is represented by a character:
L ... Logged in
S ... Stored Login...
This button brings up the server selection dialog where you can choose the destination of your login. If your stored credentials are sufficient to log you in, that's all. If you can't be logged in with stored credentials, you will be asked for your remote username and password in a separate dialog. Logout
Clicking this button logs you out from the selected server. Only root can log out other users. Store
Clicking this button stores the selected login (must be an active login) in Sharity's password database. Sharity can now log you in without asking for a password. Only root can store other users' credentials.

Security Note: Storing passwords is not secure! Although Sharity tries to encrypt the password, it must be possible to decrypt the stored information because Sharity must be able to do that without user intervention. There's no way around this security hole except NOT storing passwords. Storing passwords can be disabled in the Global configuration section.

Storing passwords is only secure if nobody except you has root-access to files on your machine. Physical access to a machine is equivalent to root access! Hackers will find a way to become root if they have an account on a machine. Delete Stored
This button removes the currently selected record from the password database. Only root can delete other users' records. PEM Pass Phrase
SSL private keys are usually stored in encrypted format and protected with a pass phrase. If Sharity connects to an SSL server and has to read a protected private key, it asks you for the pass phrase to unlock the key. Just enter the pass phrase here, the characters you type will not be displayed. Remote Username
You should enter your account name for the server here. The field is preset with your local account name, assuming that you probably have the same account name on all computers. Password
Enter your password for the server here. The characters will not be displayed as you type to avoid disclosing your password. Domain
This field should contain the domain/workgroup in which the server is located. Some servers refuse the connection if the client does not send the correct domain. Allow sending Password unencrypted
Sharity insists on sending the password encrypted to the server. However, some servers can't do encrypted passwords. If you need to interoperate with one of these servers, set this switch to on. You should be aware that your password is transmitted in clear text and everyone with a network sniffer can (and will) read it. Having access to the network cable or a computer in the network is sufficient to install a network sniffer! Store Username and Password
If you want to store your password for this server (to avoid being asked for it every session), set this switch to on.

Security Note: Storing passwords is not secure! Although Sharity tries to encrypt the password, it must be possible to decrypt the stored information because Sharity must be able to do that without user intervention. There's no way around this security hole except NOT storing passwords. Storing passwords can be disabled in the Global configuration section.

Storing passwords is only secure if nobody except you has root-access to files on your machine. Physical access to a machine is equivalent to root access! Hackers will find a way to become root if they have an account on a machine. Store Credentials as Default
If your account name and password is the same on all or at least on many computers in your network, you can save these credentials as default. Whenever you access mounts and are not already logged in, the default credentials are tried before you are asked for the password.

Security Note: Storing passwords is not secure! Although Sharity tries to encrypt the password, it must be possible to decrypt the stored information because Sharity must be able to do that without user intervention. There's no way around this security hole except NOT storing passwords. Storing passwords can be disabled in the Global configuration section.

Storing passwords is only secure if nobody except you has root-access to files on your machine. Physical access to a machine is equivalent to root access! Hackers will find a way to become root if they have an account on a machine. Cancel
If you click this button, you cancel the login process. The operation which triggered the login will fail. Revert
This button reverts all settings to their initial ones. Login
With this button you actually send your credentials to the server. Password
Enter your password for the share here. The characters will not be displayed as you type to avoid disclosing your password. Allow sending Password unencrypted
Sharity insists on sending the password encrypted to the server. However, some servers can't do encrypted passwords. If you need to interoperate with one of these servers, set this switch to on. You should be aware that your password is transmitted in clear text and everyone with a network sniffer can (and will) read it. Having access to the network cable or a computer in the network is sufficient to install a network sniffer! SHARITY(1) Sharity User's Manual NAME sharity - interact with the Sharity daemon (sharityd). LOCATION %globaldir%/bin/sharity SYNOPSIS sharity [] sharity -man DESCRIPTION This is the commandline interface to Sharity's functionality. You must pass a command name as the first parameter. The options allowed depend on the command. The following commands are currently implemented: mount -- Mount with arbitrary front- and backend modules umount -- Unmount a given mountpoint storemnt -- Store a mount or delete the stored information list -- List internal status information cifsmount -- Mount a CIFS file share cifsumount -- Unmount a CIFS file share cifslogin -- Login to a CIFS server cifslogout -- Logout from a CIFS server cifslist -- List internal CIFS status information cifslicense -- Set license key or inspect license features cifsstore -- Store a login or delete stored information cifsstoremnt -- Store a CIFS mount or delete stored information -v -- Display version information of all modules -man -- Dislpay this manual page The sharity executable calls a command automatically if it is issued under the command's name. This can be achieved by creating a symbolic link with the name of a command pointing to the sharity executable. The default installation of Sharity creates such shortcuts for all commands beginning with cifs. For more information about a command, call sharity -man Or, if the command has a shortcut, call command -man SHARITY MOUNT(1) Sharity User's Manual NAME sharity mount - Mount with arbitrary front- and backend modules. SYNOPSIS sharity mount [] DESCRIPTION The mount command mounts the backend path , which is to be interpreted in the context of the backend module, at the mountpoint using the specified frontend module. Valid options are: -h print short help and exit -r mount read-only -f mount in fake-mode (without interaction with the backend) EXAMPLES To mount a CIFS browser (which has the name "WorkgroupBrowser") at the mountpoint /WORKGROUP, you would issue the following command: sharity mount nfs2 /WORKGROUP cifsBrowse WorkgroupBrowser The mountpoint must exist prior to mounting. SHARITY UMOUNT(1) Sharity User's Manual NAME sharity umount - Unmount a given mountpoint. SYNOPSIS sharity umount [] sharity umount -a DESCRIPTION The umount command unmounts anything mounted with Sharity. You specify the mountpoint which should be unmounted unless you use the option -a, which instructs umount to unmount everything mounted with Sharity. Valid options are: -h Print short help and exit -f Unmount in fake-mode (without interaction with the backend) -a Unmount everything that's mounted by Sharity SHARITY LIST(1) Sharity User's Manual NAME sharity list - List internal status information. SYNOPSIS sharity list [] DESCRIPTION The list command displays internal status information in list format. Each module can publish status information under a list name. The main module (framework) publishes the list "mainMountList", for instance. Valid options are: -h Print short help and exit -r Raw output format (useful for scripts) -s Set string used to separate table entries. This separator is used in raw mode. The default separator is the semicolon. EXAMPLES To list all current mounts, call sharity list mainMountList SHARITY STOREMNT(1) Sharity User's Manual NAME sharity storemnt - Store a mount or delete the stored information. SYNOPSIS sharity storemnt [] DESCRIPTION This command stores a mount or deletes the stored information. If a mount is stored, it is automatically established on startup of the daemon. Valid options are: -h Print short help and exit -d Delete the stored record CIFSLOGIN(1) Sharity User's Manual NAME cifslogin - Login to a CIFS server. LOCATION %globaldir%/bin/cifslogin SYNOPSIS cifslogin [] cifslogin /// [] DESCRIPTION This command logs the calling user in to a server. While the login is established, all file accesses by the calling user are performed under the permissions available at the server with the credentials passed to cifslogin. must be the netbios name of the server where you want to log in. If the server is in share-level security mode, you must use the second form and specify the share you want to log in to. The server name must be resolvable through the netbios name service or with DNS. If neither gives an IP address, you can configure the IP address explicitly in the configuration file. Valid options are: -h Print short help and exit -U Login on server as this user. By default, the remote username is the same as the calling user's local name. -D Send this domain name to server. If not specified, Sharity's default domain is used. Some servers accept connects only from clients from their own domain. -P Password given in commandline. Using this option is STRONGLY discouraged because it will write your password to the shell's history file. -S Read password from standard input (implies -N). This option can be used if the password is created by an external program (e.g. retrieved from a database). -N Don't prompt for a password. If no password is given by the -P or -S options, use an empty password. -u Allow sending password unencrypted. Sharity does not allow sending unencrypted passwords by default (for security reasons). If you don't specify a share name for a share-level security server, cifslogin prompts the user for the share name. If the password is not supplied with the -S or -P option and if the user is not already logged in, cifslogin prompts the user for a password. CIFSLOGOUT(1) Sharity User's Manual NAME cifslogout - Logout from a CIFS server. LOCATION %globaldir%/bin/cifslogout SYNOPSIS cifslogout [] DESCRIPTION This command logs the calling user out from a server. The user will not be able to access data on the server any more, unless his or her credentials have been stored. Valid options are: -h Print short help and exit CIFSMOUNT(1) Sharity User's Manual NAME cifsmount - Mount a CIFS file share. LOCATION %globaldir%/bin/cifsmount SYNOPSIS cifsmount /// [] DESCRIPTION The cifsmount command mounts a CIFS file share at the given mountpoint and logs in the calling user to the server. Valid options are: -h Print short help and exit -r Mount as read-only filesystem -f Mount in fake mode (not connecting server) -m Use the given frontend for mounting (default is nfs2) -U Login on server as this user. By default, the remote username is the same as the calling user's local name. -D Send this domain name to server. If not specified, Sharity's default domain is used. Some servers accept connects only from clients from their own domain. -P Password given in commandline. Using this option is STRONGLY discouraged because it will write your password to the shell's history file. -S Read password from standard input (implies -N). This option can be used if the password is created by an external program (e.g. retrieved from a database). -N Don't prompt for a password. If no password is given by the -P or -S options, use an empty password. -u Allow sending password unencrypted. Sharity does not allow sending unencrypted passwords by default (for security reasons). If the password is not supplied with the -S or -P option and if the user is not already logged in, cifsmount prompts the user for a password. EXAMPLES The following command mounts the file share "C$" from the server "NTSERVER" at the mountpoint /mnt. We assume that /mnt does not exist. We also assume that root is issuing the commands: mkdir /mnt cifsmount '//ntserver/c$' /mnt -Uadministrator cifsmount will prompt for administrator's password, log in the user "root" as "administrator" on the NT server and mount the share. If other users should have access to the mountpoint, too, they must use cifslogin to log in to the server. CIFSUMOUNT(1) Sharity User's Manual NAME cifsumount - Unmount a CIFS share. LOCATION %globaldir%/bin/cifsumount SYNOPSIS cifsumount [] cifsumount -a DESCRIPTION The cifsumount command is an other name for the "sharity umount" command. It unmounts anything mounted with Sharity. You specify the mountpoint which should be unmounted unless you use the option -a, which instructs umount to unmount everything mounted with Sharity. Valid options are: -h Print short help and exit -f Unmount in fake-mode (without interaction with the server) -a Unmount everything that's mounted by Sharity CIFSLICENSE(1) Sharity User's Manual NAME cifslicense - Set the registration key or query license properties. LOCATION %globaldir%/bin/cifslicense SYNOPSIS cifslicense cifslicense DESCRIPTION The first invocation sets the license key while the second one is used to query various topics related to licensing. For the second invocation, the following options are valid: -h Print short help and exit -p Print license identifier and features -l Print current license loads and limits in terms of servers and clients -ll Print verbose listing of license utilization. For each active client, the a list of mounted servers is printed. If you reach the license limit and don't know why it's already used up, this command tells you who holds which resources. The options -l and -ll display only those other clients which use the same license key. INTERPRETING REGISTRATION KEYS Registration keys are in the following format (hex digits): PP-EEEEMM-LCCCCCCC-VVVVVVVV PP......... package index EEEE....... expiry MM......... max. network users (encoded) L.......... license type CCCCCCC.... license identification code VVVVVVVV... license verifier The registration key without the verifier part is called the "license identifier". It uniquely identifies the license but can not be used to register a copy of Sharity. Package Index: Defines for which software package the key is valid. Sharity 2 can only use licenses with package index = 02. The special Home-User / Hobbyist license available for certain binaries has package index 10. Expiry: The expiry is a 16 bit number containing the number of days from 1990-01-01 until the day of expiry. Max. Network Users: The first digit encodes the number of servers and the second the number of clients allowed by this license. The digits are interpreted as follows: value hosts value hosts value hosts 1 1 6 50 B 2 2 2 7 100 C 5 3 5 8 200 D 10 4 10 9 500 E 20 5 20 A 1 F inf. Digit values from A to E are illegel for client counts, for server counts they indicate that the number of servers is counted for the local client only, not for the entire network as usual. License Type: This number is used to distinguish between the various types of licenses (educational institution, student, business etc.). License Identification Code: This number makes your license unique. It's a kind of hash-value over your personal data. License Verifier: This is a kind of signature over the license data. CIFSLIST(1) Sharity User's Manual NAME cifslist - List logins and/or mounts. LOCATION %globaldir%/bin/cifslist SYNOPSIS cifslist [] DESCRIPTION The cifslist command displays the internal status of Sharity. If called without options, it lists all mounts and all logins. Valid options are: -h Print short help and exit -l List logins only -m List mounts only -r Raw output format (useful for scripts) -s Set string used to separate table entries. This separator is used in raw mode. The default separator is the semicolon. CIFSSTORE(1) Sharity User's Manual NAME cifsstore - Store credentials in password database. LOCATION %globaldir%/bin/cifsstore SYNOPSIS cifsstore [] DESCRIPTION This command stores your credentials in the password database or deletes stored credentials from the database. You can only store YOUR credentials from an active login at a server. The server name must be given on the commandline. Security Note: Storing passwords is not secure! Although Sharity tries to encrypt the password, it must be possible to decrypt the stored information because Sharity must be able to do that without user intervention. There's no way around this security hole except NOT storing passwords. Storing passwords is only secure if nobody except you has root-access to files on your machine. Physical access to a machine is equivalent to root access! Hackers will find a way to become root if they have an account on a machine. Valid options are: -h Print short help and exit -d Delete stored login record from the database CIFSSTOREMNT(1) Sharity User's Manual NAME cifsstoremnt - Store a mount or delete the stored information. LOCATION %globaldir%/bin/cifsstoremnt SYNOPSIS cifsstoremnt [] DESCRIPTION This command is equivalent to the "sharity storemnt" command. It stores a mount or deletes the stored information. If a mount is stored, it is automatically established on startup of the daemon. Valid options are: -h Print short help and exit -d Delete the stored record from the database