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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:38:58 PDT