Sharity

Diese Seite ist leider nicht auf Deutsch verfügbar.

Sharity 2 - Frequently Asked Questions

Mac OS X 10.4 (Tiger) Compatibility

Sharity 2.9 does not work "out of the box" on Tiger. Automatic startup at system boot is broken. To fix it, log in as an administrator user and perform the following steps in a Terminal window:

	cd /Library/StartupItems/Sharity
	sudo rm Sharity
	sudo cp sbin/sharity.init Sharity

and then reboot.

With this fix, Sharity 2 will run on Tiger with the following known bugs:

  • You must not use the "eject" function in Finder for Sharity mounts.
  • Unmounting in the Sharity GUI will hang for several seconds before it actually unmounts.
  • Finder’s caches may get out of sync with the actual directory contents. This means that it may display files which have already been deleted or it may not show files which have just been created.

Mac OS X 10.3 (Panther) Compatibility

Sharity up to version 2.8 is not compatible with Panther out of the box. This problem will be addressed in 2.9 and later versions.

You can fix 2.8 and older versions with the following procedure:
Open a Terminal window and copy the following lines line by line, typing the Return key after each line:

  setenv PATH ${PATH}:/Library/StartupItems/Sharity/bin
  sudo cifsstoremnt -d /Network/CIFS
  sudo sharity mount nfs2 /CIFS cifsBrowse browser
  sudo cifsstoremnt /CIFS

You must be an administrator and type your password when asked.

If the first command (the setenv) fails, you probably use a different shell. In this case simply replace it with

  export PATH=$PATH:/Library/StartupItems/Sharity/bin

Sharity an Windows XP Servers

Windows XP has a lot of configuration options affecting the CIFS/SMB server. Depending on how your installation was made, you may not be able to connect with Sharity in the first place.

As a general rule: Sharity behaves similar to a Windows 95/98 client. Every setting XP needs to serve these clients will probably be needed to serve Sharity, too.

In particular, make sure that your network settings are in expert mode. If you want to connect as local user, also start the administrative tool “local security policy”, select security policies / local policies / security options, choose “network access: sharing and security model for local accounts” and then pick “classic - local users authenticate as themselves”.

If you find other settings required by Sharity, please report them to sharity-support@obdev.at.

On Mac OS X: I don’t have permissions to install Sharity

Some people report that they can not drag the folders of the Sharity distribution to the destinations indicated in the Readme file.

If you experience this problem: LEAVE THE SYSTEM FOLDER ALONE! You don’t have permissions to modify the System folder and this is intentional. Sharity should be installed in /Library and /Applications, NOT in /System/Library.

It is also possible (although unlikely) that you don’t have permissions to the /Library folder. Due to Apple’s installer application, software which comes as a .pkg package can modify your folder permissions during installation. To repair the permissions of your /Library folder, open a Terminal window (Terminal is at /Applications/Utilities) and type:

sudo chown root.admin /Library
sudo chmod ug+rwx /Library

You will have to type your password. If you don’t have permissions to the /Library/StartupItems folder, repeat the above for this folder, too.

My CIFS folder is empty…

First of all: Do you care about browsing? You can add a couple of servers by hand, if you don’t care. To do so, do the following: Open the GUI, change to section “CIFS Servers” and click the “Add” button to add each server. This should suffice if your WINS setting is correct. If it is not, you must configure each server’s IP address, too. All explicitly configured servers will appear in the CIFS folder, regardless whether they are in your workgroup or not.

If you care about browsing: There are known problems with browsing in Sharity 2.4 and older. Please get 2.5 beta 2 or newer, browsing has been greatly improved in these versions.

If the CIFS folder still does not work after upgrading, please be sure to check your configuration settings for the “browser” browser’s domain and the WINS server (in the “CIFS Browsers” and “CIFS General” sections of the GUI respectively). If you are sure that both are correct, it’s possible that there are no Windows or Samba computers in your network segment which can provide the browse service Sharity needs.

If there is no browse server available in your network segment (or at least not reliably available), simply install Samba on your machine. It provides the browse service required by Sharity. Mac OS X now comes with Samba bundled. You can enable it as “Windows file sharing” in the Sharing preferences.

If browsing still does not work even after installing samba, you can use samba’s commandline tools to debug the problem. The nmblookup tool is most useful for this purpose. The command

nmblookup -M YOUR_DOMAIN_NAME

looks for the master browser of your domain. The command

nmblookup -M -

looks for all master browsers of all domains in your network segment. Sharity does not only need the master browser’s IP address, it also needs its name. You can check whether Sharity can obtain the name of the master browser with

nmblookup -S -M YOUR_DOMAIN_NAME

which also looks up the node status of your master browser.

Files copied by Sharity are not visible on Windows

As a Unix tool, Sharity tries to preserve the Unix “execute” file attribute. Since there is no direct analogon for this in DOS, Sharity must map it to one of the DOS file attributes. The default setting is to map Unix “execute” to the DOS “system” attribute.

The default setting on most Windows installations is to hide files with the system attribute from users. Due to Sharity’s mapping, executable files are hidden on these Windows installations.

There are two ways to work around this problem. First, you can simply change your Windows preferences to show system files as well. And second, you can change Sharity’s “execute” mapping strategy. This is done in the GUI in section “CIFS Servers” in the setting “Take Execute Permission From”. Please read the associated help item before you change this setting.

Sharity on AIX 4.3.3 - Patch information

Sharity does not work on some AIX 4.3.3 systems. All attempts to mount anything fail with an “Invalid argument” error.

This is caused by a problem in the AIX mount system call, similar to the AIX 5L problem described in an other note. IBM has released a fix under the name IY29404. It is recommended that you upgrade to maintenance level 11, which includes this fix.

Sharity on AIX 5L - Patch information

If you have upgraded the package bos.net.nfs.client to a version newer than 5.1.0.14, Sharity may fail to mount anything. All mounts will abort with the error "Invalid argument".

There is a patch available from IBM for this problem. Please direct your web browser to the URL http://techsupport.services.ibm.com/server/aix.fdc and search for the APAR number IY31034. Follow the instructions in the README file of the package you can download from IBM.

It is likely that this fix will be included in a future version of AIX 5L.

On Mac OS X: I get “Error connecting to daemon…”

Are you sure that you have dragged the Sharity folder from the distributed disk image to the /Library/StartupItems folder and NOT to /System/Library/StartupItems?

If you are sure you have dragged it to the right destination, it’s possible that your disk image is damaged. Due to a bug in the current releases of Mac OS X, some people can’t mount disk images correctly. In this case please download the .tar.gz package instead of the .dmg.gz one.

All mounted shares appear on my Mac OS X Desktop…

It’s an Apple tradition to display icons for all mounted resources on the desktop. Since this may become annoying if you mount many servers, Apple has added an option to turns this off in Finder.

To disable the icons for connected network resources on the Desktop, open Finder, select the menu item “Finder/Preferences…” and uncheck the checkbox “Connected servers” in the section “Show these items on the Desktop”.

All the files mounted by Sharity have read-write permissions for everyone. Isn’t this terribly insecure?

No, it is not. The Unix permissions you see in ls -l are never used for access control. They are a fake. The real permission checks are done by the server based on the credentials you provide during login and based on Access Control Lists or whatever other mechanism the server provides to limit access. You can try it. Try to access the world-readable files as an other user (except root) who has not logged in. You will get an “Access denied” error.

Connecting to my server fails…

Connecting to servers is a complex process consisting of multiple steps. This text is dedicated to problems where connecting fails during the very first steps. If you can browse shares of your server or get an “Access Denied” error during login, a basic connection is established and you should skip to a more specific knoledge base entry.

Error messages indicating general connection problems contain the phrases:

  • Connection refused
  • Timed out
  • Netbios Session refused

Other indications for general connection problems are that the server appears in the CIFS folder, but you can’t see any shares when you click it although you know that shares are exported.

There are three things involved in a basic connection:

  • Resolving the computer name to an IP address
  • Connecting to port 139 on that IP address
  • Negotiating a connection with the Netbios layer

If you are not sure whether name to IP resolution works, you can explicitly confgure an IP address for the server in Sharity’s GUI. Go to the “CIFS Servers” section, add the server by name, go to expert mode and set the server’s IP address. If this solves your connection problem, your WINS server does not work. Please check the IP address configured for the WINS server in the “CIFS General” section of Sharity.

If connecting still fails with an explicitly configured IP address, you should try to connect with other tools. If you don’t have samba installed and can’t use smbclient to test, we recommend the following: Open a Terminal window (on Mac OS X, Terminal is at /Applications/Utilities) and type:

telnet server-ip-address 139

(replacing server-ip-address with the server’s IP address, of course). You can expect one of 3 possible reactions from telnet:

  • Telnet sits there trying to connect, eventually timing out after a couple of minutes.
  • Telnet prints a “Connection refused” message.
  • Telnet prints “Connected to…” and sits there waiting for your input.

If it’s one of the first two, you have a general network problem. Check whether there’s a firewall which blocks port 139, whether your routing is correct, whether you can ping the server and whether the server has TCP and Netbios over TCP installed. If you manage to connect with telnet, the netbios layer must have refused the connection.

If you get the “Netbios Session refused” error, the most likely cause is that the computer name you used for the server does not match the server’s actual Netbios name. Please double-check with the server’s configuration or with the server administrator. It’s also possible that the server service has not been started on the server.

If all of the above did not solve your problems, you might find more information in the syslog. On Mac OS X, open the Console application and search for messages containing the word “sharity”. On other Unix platforms, the syslog is usually in a file at /var/log. See your syslog configuration in /etc/syslog.conf for details.

Files greater than 2 GB in size don’t work

Sharity’s current implementation uses NFS version 2 to communicate with the kernel. It therefore inherits a limit of usually 2 GB for file sizes and offsets from NFS 2.

Handling of Resource Forks on Mac OS X

Sharity does not handle resource forks by itself. It presents a Unix file system to Mac OS X. The Carbon framework can emulate the old Mac features (such as resource forks) on top of Unix file systems. This information is stored in files beginning with “._”.

The consequences of this approach are: If you rename, move or otherwise handle the files on Windows, the files and their resource forks become separated and you lose all the resource information. Similarly, if you have files created with Windows NT’s AppleShare, these files won’t follow Carbon’s conventions and you will lose the resource fork data.

How do I access my Mac from Windows?

You need Samba. Samba is a CIFS server for Unix and it’s free. Newer versions of Mac OS X come with Samba bundled. You can enable it in the “Sharing Preferences” as “Windows file sharing”.

If you have an older version of OS X without Samba, you can download an easily installable Mac OS X package from e.g. http://xamba.sourceforge.net/sambax/index.html

How do I preserve my settings during an upgrade?

Sharity distinguishes two kinds of setting: public and secret settings. Secret settings are stored login credentials and the license key. You can’t save secret settings across an upgrade. You can’t even save them in a backup. This is to avoid that such sensitive data gets stolen. Public settings are stored in the file

/Library/StartupItems/Sharity/var/cfgdb.ppl

on Mac OS X or in

/usr/local/sharity/var/cfgdb.ppl

on other Unix operating systems (unless you have changed the installation pathes, of course).

If you save away this file before uninstalling and restore it after you installed the new version, you will retain your settings. You can even browse the file in a text editor to see what you have changed from the defaults.

I can’t write files to my PC, although the permissions are wide open!

There’s a bug in the current version of Finder. It refuses to write to the root of the mounted shares. You can write to any subdirectory, though, as long as you have the permissions on the server. Writing from Unix or Cocoa applications should work, too.

I had a kernel panic. What do you need to debug the problem?

A kernel panic is a bug in the operating system kernel, not in Sharity. Contrary to what many people think, Sharity does not extend the kernel, it is an ordinary user-level program. It can trigger kernel panics like every other user-level program, but the bug is still in the kernel. Please report the kernel panic to the operating system vendor. If you are using an open-source operating system (such as Mac OS X, Linux or FreeBSD), please also report the panic (with as much information as you can provide) to us. We might have more information for the kernel developer or we could even have a patch.

I have mounted a share as root, but I can’t access it as user. Why?

You are not running the Sharity GUI but rather use Sharity from the commandline, right? What you experience is a feature, not a bug. For security reasons Sharity requires that every user who wants to access data on the server must authenticate to the server. If you mounted as root, you have authenticated root to the server, but no other user. If you run the GUI, Sharity will pop up a window and ask you for your remote credentials when it needs a password. The login works therefore automatically as long as the GUI runs. If it does not run, you must provide your credentials manually prior to accessing data. Use cifslogin to login to the remote server. See cifslogin -man for more information.

I have moved Sharity to the Trash. Now I can’t emtpty the Trash!

This is not really a Sharity question but rather a general Mac OS X question. If there is something in the trash which you can’t delete, please do the following:

  • Find out which item is undeletable
  • Create a folder named DeleteMe in your home directory
  • Drag the undeletable items into this folder
  • Open the Terminal application (located at /Applications/Utilities).
  • Burn the folder with the magic words (in a newly opened Terminal window):
        sudo rm -rf DeleteMe

    Be sure to write the line exactly as written here! The rm command deletes its argument with absolutely no way to restore!

I own a Sharity 2.3 license. How much costs upgrading to 2.4?

Nothing! Upgrades within the same major release number are generally free!

Sharity keeps writing “Connection reset by peer” messages to my syslog. What does this mean?

The CIFS protocol allows the server to break the connection after a certain time of inactivity. This is completely normal procedure and does not degrade Sharity’s performance or reliability. Sharity logs this event to the syslog for informational purposes. If you are annoyed by the message, edit the file /usr/local/sharity/etc/sharity.cfg and disable the logLevel smbConnect.

Sharity mounts can not be accessed from Mac OS X Classic

Classic applications can’t use Sharity. This is a limitation of Mac OS X: Classic can not access any Unix file systems. As a workaround you can copy the files to a local HFS partition with Finder, work on them with the Classic application and the copy them back with Finder.

The problem will go away when all the major Mac applications are available in Carbonized versions.

Sharity’s browsing does not seem to work on AirPort

Wireless LAN products such as Apple’s AirPort are usually configured to work as a network router, not a bridge. AirPort therefore does not pass UDP broadcast messages. Since Sharity’s browsing of computers in your network neighborhood depends on UDP broadcasts, the CIFS folder will be empty on notebooks connected through AirPort.

If you use Sharity on a notebook connected through AirPort, please choose one of the following workarounds:

  • Install Samba on the notebook
    If samba is installed and correctly (!) configured, it will act as a local browse server for Sharity. Sharity can reach this browse server with broadcasts and can thus display the browse list.
  • Configure your servers explicitly
    Open Sharity’s GUI, go to the section “CIFS Servers” and add your servers by name. If you use a WINS server, that’s all you need to do. If not, you will also have to configure IP addresses for the servers in expert mode.
  • Set up your network to use a WINS server and a Domain Controller
    Complex networks with routers must usually be configured to use WINS servers and Domain Controllers. If you have configured your network this way, Sharity should work as expected.

Unmounting always fails with a “Device busy” error

There is a bug in the Mac OS X kernels prior to xnu-125 and in Finder. You can work around the Finder bug, but you need a patched kernel in order to unmount.

When I try cifsmount with the server’s IP address from the commandline, I get a “Netbios session refused”. Why?

You must not use IP-addresses with Sharity. You must use the server’s correct netbios name. If this name does not resolve to the correct IP address either with Netbios nameservice or with DNS, you can add an explicit server configuration in Sharity’s GUI specifying the IP address. If can’t use the GUI for whatever reason, you can also add an entry to the /etc/hosts file.

You can’t access directories which are more than 3 levels deep.

You are using Sharity without an license key. In demo-mode Sharity is limited to 3 levels of directory hierarchy. The binaries with "home" in their name don’t have this limitation because they have a "Sharity Single" license built-in.