Problem with MacOS 9 Multiple Users and Netware AFP

[dlambert () UMICH EDU (Don Lambert)]

Hi all,

I ran into a problem with MacOS 9's Multiple Users feature 
and Netware AFP.
MacOS 9 tries to create a Users folder at the root level 
every mounted
volume. The behavior occurs on locally mounted volumes 
(including SCSI, IDE,
and floppies). It also occurs on volumes accessed by 
AppleShare. The Users
folder seems to be loosely analogous to the %System 
Root%\Profiles\
directories that get created in Windows NT. Unfortunately, I 
wasn't able to
find much info on the purpose and functionality of the Users 
folder at
Apple's site. In the case of MacOS 9 creating the folder on 
Netware AFP
servers, the resulting Users folder gives excessive rights 
(RWCEMF) to
[Root]. The problem occurs on servers running AFP when users 
connect via
AppleShare in the Chooser. It does not occur when logging in 
using the
Prosoft Client for MacOS. I was able to duplicate the 
problem on both a
Netware 4.11 server and a Netware 5 server. My testing steps 
are below. At
the end of the message I present a workaround:

Test 1 [Netware 4.11, AFP 4.10, MacOS 9, bindery connection 
through Chooser]
:

This test involves AFP 4.10 NLM running on a Netware 4.11 
server (SRVR1).
The client side is MacOS 9 running in Multiple Users mode. 

Created user - chooseruser in the same container as the 
server. Give
chooseruser read, create, and filescan to the root of 
SRVR1_DATA1 volume. On
the MacOS 9 Mac, log into SRVR1 as chooseruser via a bindery 
connection
through Chooser (no NDS client involved) and mount DATA1. A 
Users folder is
created at root of DATA1. Checking in NWADMN32, I see that 
chooseruser is
the Owner of this. No other trustees are listed for the 
Users folder.

Now I Log out chooseruser from SRVR1 on the Mac. I give 
chooseruser read,
create, filescan, and access control to the root of 
SRVR1_DATA1 volume. On
the MacOS 9 Mac, log into SRVR1 as chooseruser via a bindery 
connection
through Chooser (no NDS client involved) and mount DATA1. A 
Users folder is
created at root of DATA1. This time when checking in 
NWADMN32, I see that
[Supervisor] is the Owner. When I check the Trustees, I see 
that [Root] is a
trustee with Read, Write, Create, Erase, Modify, and File 
Scan. I see that
[Supervisor] is a trustee with Read, Write, Create, Erase, 
Modify, File
Scan, and Access Control.

Now, I log out chooseruser and give the account RWCEMFA 
access to the root
of the DATA1 volume. I log in as chooseruser again through 
the Chooser and
mount DATA1. When I look at the existing Users folder, I 
would expect that I
should be able to copy a file to it. The MacOS says I only 
have See Folders
and See Files privileges (i.e. read & file scan). It appears 
that the MacOS
is putting limits on my access to the Users folder over and 
above what NDS
is doing. When I log into MacOS 9 with a Mac Owner Account 
(that's an
account run by MacOS 9 Multiple Users), and then log into 
SRVR1 as
chooseruser, I can mount DATA1  and have my normal NDS 
granted access to the
Users folder. I also get the regular access Users folder if 
I turn off the
Multiple Users functionality and mount the DATA1 volume.

Test 2 [Netware 5, AFP 4.53, MacOS 9, bindery connection 
through Chooser]

Test 2 is pretty much the same test as Test 1, but instead 
of using Netware
4.11 and AFP 4.10, I used Netware 5 and Prosoft's AFP 4.53 
on the server
end. The server is SRVR2. The results are same as in Test 1. 
The testing
steps are below.

Give chooseruser read, create, and filescan to the root of 
SRVR2_DATA2
volume. On the MacOS 9 Mac, log into SRVR2 as chooseruser 
via a bindery
connection through Chooser (no NDS client involved) and 
mount DATA2. A Users
folder is created at root of DATA2. Checking in NWADMN32, I 
see that
chooseruser is the Owner of this. No other trustees are 
listed for the Users
folder.

Now I log out chooseruser from SRVR2 on the Mac. I give 
chooseruser read,
create, filescan, and access control to the root of 
SRVR2_DATA2  volume. On
the MacOS 9 Mac, log into SRVR2 as chooseruser via a bindery 
connection
through Chooser (no NDS client involved) and mount DATA2. A 
Users folder is
created at root of DATA2. This time when checking in 
NWADMN32, I see that
[Supervisor] is the Owner. When I check the Trustees, I see 
that [Root] is a
trustee with Read, Write, Create, Erase, Modify, and File 
Scan. I see that
[Supervisor] is a trustee with Read, Write, Create, Erase, 
Modify, File
Scan, and Access Control.

Test 3 [Netware 4.11, MacOS 9, Netware Client for MacOS 
5.12, NDS Connection
using NW Client]:

This test uses SRVR1, a Netware 4.11 server again. It also 
uses MacOS 9 with
multiple users and Prosoft's Netware Client for MacOS 5.12.

Next, I tried the same tests as above, but I used a user 
called prosoftuser
in the same container as SRVR1. I deleted the Users folder 
from the above
tests off of DATA1. I used the Prosoft NDS Client for MacOS 
5.12. I logged
into NDS as prosoftuser. Next, I used the Prosoft Netware 
volume mounter in
the Chooser to browse through NDS to the SRVR1's container 
and mount the
SRVR1_DATA1 volume via IPX. Even when prosoftuser has 
RWCEMFA rights to
DATA1, no Users folder is created by MacOS 9. However, as 
soon as I use
prosoftuser to do a bindery connection using AppleShare in 
the Chooser, a
Users folder gets created with the Owner being [Supervisor] 
just as in the
previous tests.

Test 4 [Netware 4.11, MacOS 9, Netware Client for MacOS 
5.12, bindery
connection using NW Client]:

This test uses SRVR1, a Netware 4.11 server again. It also 
uses MacOS 9 with
multiple users and Prosoft's Netware Client for MacOS 5.12.

For this test, I first made sure that there wasn't a 
previous Users folder
on the server from previous testing. I logged prosoftuser 
into NDS using the
Netware Client for MacOS 5.12. Next, I used the Netware 
volume mounter in
the Chooser to mount DATA1 on SRVR1 using a bindery 
connection. In this
case, the Users folder did not get created by MacOS 9 
despite prosoftuser
having RWCEMFA rights to DATA1.

Workarounds:

The Users folder will not get created if a Users folder 
already exists at
the root the volume. Also, [Root] does not get added as a 
trustee to a
pre-existing Users folder. Thus the only step you need to 
take to stop the
MacOS 9 issue from affecting your server is create a folder 
called Users at
the root of every volume that is accessible via AFP.

I did not find any info about this problem at Apple's, 
Novell's or Prosoft's
sites. If anyone has any insight on to why MacOS 9 needs to 
create a User
folder on every volume, please let me know. Also, any ideas 
on why Netware
gives [Root] access to the Users folder that gets created?

Terry Miller
Computer Aided Engineering Network
University of Michigan

Don Lambert 
Computer Aided Engineering Network
University of Michigan