Macintosh File Server (MFS) for BeOS
Version 1.5
Copyright © 2002-06, SomeGuy Software. All Rights Reserved.
Contents
1 Introduction
1.1 What's supported
1.2 What's not supported
1.2.1 Currently unsupported AFP
API's
2 Installation
2.1 Getting MFS to start
automatically
2.2 Installing the BeUAM
3 Configuring MFS
3.1 Managing Users
3.2 Creating a drop-folder
3.3 Setting Permissions
4 Known issues
5 License
6 Support
7 Disclaimer
8 What's New
1 Introduction
Welcome to the Macintosh File Server (MFS) for BeOS! This
multi-threaded server, written from the ground up for the BeOS, will
allow Macintosh clients to share files with a BeOS machine. Once MFS is
installed, Mac clients can connect using their native AFP protocol to
shares on the BeOS machine.
1.1 What's Support
Currently, MFS implements the AFP 3.2 specification and is compatible
with either Classic MacOS or Mac OS X clients. The only restriction is
that the Mac clients must support AFP over TCP/IP (AFP 2.2 which first
appeared in AppleShare 3.7 or later).
MFS is probably best suited for personal use. I have not and cannot
test the server in a production or other high load environment. I'd be
interested in hearing how you deploy this server and how it holds up.
NOTE: MFS has been hammered with stress testing tools, so I think it is
fairly solid. But no test tool, no matter how well written, can really
duplicate real life. So consider yourself forewarned.
1.2 What's not supported
WARNING: There is no folder level security! The BeOS provides no
infrastructure to provide this.
AppleTalk connections are not supported. This could be done but I can
find any documentation so far describing how to access the AppleTalk
stack included with the BeOS. But, to be honest, even if it were
possible to do I don't know if I would do it since AppleTalk is a dying
protocol that even Apple® is shying away from.
1.2.1 Currently unsupported AFP API calls
The following AFP API calls are not supported in this release of MFS.
Note that the absense of all the API's below does not affect the
usability of this server with
Macintosh clients. The only reason I list these here is in case a
developer tries to write a custom application that attempts to use
these calls.
FPOpenDir (not required)
FPDirClose (not required)
FPMapName (irrelevant since BeOS doesn't support
users)
FPSetVolParms (irrelevant since BeOS doesn't support
a backup date)
FPDeleteID (don't have too according to spec - not
possible with Be file system)
FPResolveID (don't have too according to spec - not
possible with Be file system)
FPExchangeFiles (not required)
FPGetAuthMethods (irrelevant since BeOS doesn't
support users)
FPCatSearch (not required)
FPCatSearchExt (not required)
NOTE: FPGetDirParms and FPGetFileParms have been depricated and won't
be supported.
2 Installation
To install MFS, just double click the installer.sh script from within
tracker or run it from Terminal. It will place all the files in their
appropriate places. Specifically, it places the following files:
home/config/bin/afp_server
<--this is the AFP server
service
home/config/bin/MacFile
<- this is
the configuration utility
home/config/be/Applications/MFS
<--link
home/config/be/Preferences/MacFile
<--link
2.1 Getting MFS to start automatically
To get MFS to start automatically on boot, you will have to manually
edit your UserBootScript file. Just copy the following into your
UserBootScript file located in home/config/boot.
#!/bin/sh
#
SCRIPTS=beos/system/boot
SERVERPATH=home/config/bin
launchscript() {
if [ -f "/boot/$1" ]
then
.
"/boot/$1"
fi
}
start()
{
if [ -f /boot/$1 ]; then
/boot/$1 $2 &
else
echo There
is no $1
fi
}
launchscript
$SCRIPTS/Netscript #
start up networking
start $SERVERPATH/afp_server
In a future release, I hope to relieve users of this installation step.
Any tips (script code) on how I can do this automatically without
blowing away the current boot script would be appreciated.
2.2 Installing the BeUAM
Beginning with version 1.1 of MFS, a custom UAM is supplied that you
can install on your MacOS X Macintosh to provide you with increase
security by encrypting your passwords when logging into your MFS
server. After you run the installtion script, you'll find a folder
called "BeUAM_Volume" at the root of your home folder. This folder is
shared as a MFS volume that you can access from your Macintosh. On this
volume is an installer that will install the BeUAM onto your Macintosh
to provide better login security. Be sure you set the proper
permissions on this volume so the appropriate users can access it (see
section 3.3 Setting Permission below).
3 Configuring MFS
Once MFS is installed and running, you can use the MacFile preference
application to configure:
1. What directories you are sharing
2. What users have access to your computer via AFP
3. What message (if any) users will see when they
log in.
3.1 Managing Users
MFS provides a rudementary user authentication system. With the MacFile
preference application you can allow only certain users to access your
computer by entering user names and passwords. You can also tell MFS
who has admin priveleges. Currently, "Admin Priveleges" only means that
users are listed as "owners" of the shares. This way, window positions
and listing types are saved between logins. If you are not an "Admin",
you are basically just a normal user.
3.2 Creating a drop-folder
There are many instances where you may want to create a drop-folder
that Mac clients can drop files into but cannot open or view. To do
this in MFS for BeOS just name any folder "~DropFolder~" (without the
quotes). Users without admin privilages will not be able to open or
view this folder but can drop files into it. Admins will have full
access to the folder.
3.3 Setting Permissions
Beginning with version 1.1, MFS uses the Be filesystem's permission
attributes to provide at least some rudimentary directory access
control. With prior versions guests had full read/write access to all
shares and directories just like normal users, this is not good. Now,
MFS uses the Posix permissions available in the Be filesystem to
control access for guests and normal users.
To set directory permissions in the BeOS, we recommend you install and
use OpenTracker (http://www.bebits.com/app/1220) as it provides easy
access to directory permission via "Get Info..." by right clicking on
any folder.
Permissions are set as in the table below. Normal user permissions are
reported to the Mac client as they are set by the "Group" column. Since
groups are currently not supported in BeOS, we borrow these settings
for normal user access permissions. Guest access is controled by the
settings in the "Other" column. In the example below, Users have full
read/write access to the sample directory and guests have just read
only.
Owner Group Other
Read X
X X
Write X
X
Execute X
X X
The execute access settings are not understood by Macintosh clients, so
we use this setting to determine whether or not Mac clients can view
the files in a particular directory. To look at the chart above as it
should read in MFS and/or Mac clients, look below for the translation:
Owner Users Guests
Read X
X X
Write X
X
Search X
X X
Below is an example of how you would create a drop folder if you don't
want to use the naming convention described in the previous section. In
the below example, users and guests can copy files into a particular
directory, but cannot open it to view it's contents. Note that you do
not want to apply these settings to the root directory of an MFS volume
(the shared folder) otherwise users and guests will not be able to
mount the volume.
Owner Group Other
Read X
Write X
X X
Execute X
Admins continue to have full unrestricted access to all shares and
directories on a particular server. The "Owner" bits are ignored at
this time as their meaning is irrelevant.
4 Known issues
Performance: I can only write the server as good as the BeOS networking
API's allow me too. Please don't complain about the performance unless
you think it is REALLY bad and you feel you just have to vent on me.
Actually, I must say that MFS is showing better performance than I was
anticipating when I started the project given the lame networking API
set (I hope the Haiku folks fix this).
Resource Forks: Because of an incomplete implementation of file
"attributes" by Be, when reading from or writing to the resource fork
of a Macintosh file, MFS must read in the entire fork to memory, then
manipulate, add to or read from it. This could take a very large amount
of memory if the resource fork is of substantial size. Thank goodness
Apple is moving away from resource forks in MacOS X. And again, I hope
the OpenBeOS file system developer reads this (I need the offset and
length parameters to work when reading from/writing to file attributes).
Renaming files/dirs to long names: For files with long names (longer
than 32 characters), you can read them from the server and copy them to
the server. However, you cannot rename an existing file on the server
to a longer name. I don't know why this is, the client stops the action
without even making a request to the server, so this looks like a
client issue.
Tested Clients: This server has only been tested with MacOS 8.0, 8.6,
9.1, 9.2.1, MacOS X 10.1.x, 10.2.x and 10.3.x clients. Please let me
know if any other clients work (or don't).
There appears to be a bug in the MacOS X AppleShare client that
prevents the changing of passwords when the password is expired. This
is supposed to be allowed but I cannot find a way around it yet.
5 License
You may use MFS for FREE. I wrote MFS because it filled a personal
need, I hope someone else finds it useful too.
6 Support
Report any bugs or issues to some_guy_software@hotmail.com. I cannot
commit to answering all letters, but I can promise that I will read
them all. I also cannot commit to implementing or fixing every request.
I do this on my spare time and too often "real life" gets in the way.
7 Disclaimer
The term "Software" refers to the MFS applications, add-ons and
documentation.
DISCLAIMER OF WARRANTY. The Software is provided on an "AS IS" basis,
without warranty of any kind, including without limitation the
warranties of merchantability, fitness for a particular purpose and
non-infringement. The entire risk as to the quality and performance of
the Software is borne by you. Should the Software prove defective, you
and not Some-guy Software assume the entire cost of any service and
repair. This disclaimer of warranty constitutes an essential part of
the agreement.
LIMITATION OF LIABILITY. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL
THEORY, TORT, CONTRACT, OR OTHERWISE, SHALL SOME-GUY SOFTWARE OR ITS
SUPPLIERS OR RESELLERS OR DISTRIBUTORS BE LIABLE TO YOU OR ANY OTHER
PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF
GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND
ALL OTHER COMMERCIAL DAMAGES OR LOSSES. IN NO EVENT WILL SOME-GUY
SOFTWARE BE LIABLE FOR ANY DAMAGES, EVEN IF SOME-GUY SOFTWARE SHALL
HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM
BY ANY OTHER PARTY.
8 What's New
Version 1.5
- Added support for changing password from the Mac client. This will
work using either the standard Apple UAM (clear text) or the supplied
SG-UAM (encrypted).
- Added several more user configuration options around passwords
- Fixed bug where guest allowed setting wasn't always saved
- Now hide password in user configuration dialog
- SG-UAM
- Fixed some UI glitches
- Updated with change password support
- Improved performance a bit, you can now watch media such as QuickTime
movies opened directly from a share.
Version 1.4
- Added support for extended file/dir attributes (FPGetExtAttr,
FPSetExtAttr, FPListExtAttributes, FPRemoveExtAttr) as per AFP3.2
specification.
- Fixed bug introduced by new AFP3.2 client where some files could not
be saved from the mac client.
- Fixed bug where the client<->server connection would be torn
down if the client went to sleep. Now connections will stay alive up to
24 hours if the client goes to sleep (as per AFP spec).
Version 1.3.2
- Fixed bug introduced in 1.3.1 that caused file to not be displayed
properly on mac client.
Version 1.3.1
- Now get the network host name from the OS so it is properly displayed
in the logon screen from Mac clients.
- Proper host name is reset when networking is restarted
- Slight improvement in read performance
Version 1.3
- Can now send messages to all connected clients
- Updated UI to be a little cleaner and friendly
- Fixed bug in logon message where first character didn't display on
Mac client (Apple finaly updated their documentation)
- Fixed IP address displayed on Mac clients when connecting to x86
servers. Will now show server name as "Be[<your server's IP
address>]".
Version 1.2
- Fixed bug where reads weren't returning EOF error when appropriate.
This affected operations like Stuffit Expander expanding .hqx files
where it relies on the EOF message to know when it's done.
- Fixed minor bug in the desktop database
- Improved BeUAM encryption for a more secure login. All users should
update the BeUAM on their MacOS X 10.1 or later Macs.
Version 1.1
- Now include a custom User Authentication Module (UAM) for MacOS X
clients
- Now use the Be filesystem permissions to provide some restrictions to
guest and users
- Fixed bug where the server wasn't properly stopping the sharing of
folders that moved or were deleted
- Completely re-wrote the server networking code to accomodate
net_server based installations better
- Classic MacOS disconnect issues appear to be solved with rewrite above