View Full Version : Crazy Scary permissions florf?

10-10-2003, 05:19 PM
So all of the talk in jacob's (http://forums.macgurus.com/6/ubb.x?a=tpc&s=40160367&f=70160549&m=711607704) thread about the Server permissions bug(s) got me looking at our Server box - QS 733 running 10.2.6 Server, upgraded all way from 10.1.3 Server. I unchecked admin from one user (the only other "admin" account), deleted a couple of non-admin users that I knew were long dead, and also deleted some netboot users long dead as well. Normal admin stuff done in the Workgroup Manager app, nothing fancy or manual in the terminal...

I decided to repair permissions and run disk utility on the two volumes that are on a second drive while I am there. Both are reported fine with no errors or problems, but one will not remount. OK, no problem I will just reboot.

Reboot. neither volume mounts. Fearing a failing HD or snarfed up directory, I run DW 3 from CD, which sees and reports all volumes as fine (repairs very minor errors).

Reboot. neither volume mounts. OK, maybe a bad drive, cable, or OS trouble. Machine is booting to the first volume fine, everything else looks good, just the second drive (two volumes) won't mount.

So I throw the drive in question in another G4 running Jag, and what-da-ya-know, it mounts fine, everything looks perfect. I decide to backup the first drive (users and other data/sharepoints) via CCC on a FW drive that I always use with this G4.

Whoa, FW drive won't mount now, but Disk Utility sees it, just like the florfed drive.

OK, repair permissions again and reboot. Nothing.

Start looking at permissions manully; Mac HD (boot drive) has No group whatsoever. Blank. And there is no "admin" in the group list.

If I select "staff", reboot, and the FW drive mounts, but not the second internal drive... If I login as root, the drive does not mount. After backing up, I try to reinstall 10.2.6 Server (cause I *know* I don't know how to manually set system permissions), but can't get the RAM disc to mount: error 95.

(to be continued...)


Charlie Don't Surf!

[This message was edited by unclemac on Sat October 11, 2003 PT at 12:07.]

10-10-2003, 09:22 PM
OK, so let's recap: second drive won't mount, a struggle to mount a FW drive, and the update RAM disk won't mount... what is going on?

I open the updater on a second machine, transfer the installer back and run it to reinsyall 10.2.6 Server. No problems.

Reboot. Same thing - volumes don't mount. Repair permissions *again*, reboot, same thing. Reboot again and log in as root...

Sucess! All volumes mount. So... maybe the problem is related to something specific to my "admin" acount. So I create a new admin account, reboot, and *poof* the two volumes are gone again.

http://forums.macgurus.com/infopop/emoticons/icon_mad.gif http://forums.macgurus.com/infopop/emoticons/icon_mad.gif http://forums.macgurus.com/infopop/emoticons/icon_mad.gif

Reboot as root, and the volumes are back.

http://forums.macgurus.com/infopop/emoticons/icon_confused.gif http://forums.macgurus.com/infopop/emoticons/icon_confused.gif http://forums.macgurus.com/infopop/emoticons/icon_confused.gif

I have done a bit of testing and all looks good for users connecting so far, and in fact the permissions for the 50 Gigs of files on the two volumes of the "here-it-is, whoops-no-its-not" drive appear to be correct and unchanged through all of that.

At this point, all that I can think of (that I have not tried) is updating to 10.2.8 Server, which is merely blind hope. Not that deperate - yet.

What on earth, perhaps related to permissions not repaired by "repairing permissions", or maybe a user pref, can cause drives not to mount?



Charlie Don't Surf!

[This message was edited by unclemac on Fri October 10, 2003 PT at 22:42.]

10-10-2003, 11:04 PM
Is it possible that the drive's mounted, but just not showing up in Finder? (This is one them WAGs, not a certainty 'cause I ain't never actually seen this.)

You didn't say how it was that you observed it not mounted. Did you check only in Finder or also in Terminal? In a terminal session (Terminal app or via ssh to the machine), enter the mount command, with no other options, and it reports all mounted volumes of any type. Does it report the volumes mounted even when you can't see 'em in Finder?

I don't believe that "who's logged in" affects what's mounted (but see Note 2, at the end).

First thing to check: did repair permissions (I've never trusted that program!) set the user, group, and filemode of the /Volumes directory such that your "admin" users can't read/execute through it? Do this in Terminal (possibly need to be root):

<pre class="ip-ubbcode-code-pre">ls -ld /Volumes</pre>
(that's "ell-ess dash-ell-dee"). Output should look like:

<pre class="ip-ubbcode-code-pre">drwxrwxrwt 12 root wheel 408 Oct 10 22:06 /Volumes</pre>
If the permissions on the /Volumes directory won't allow an "admin" user to walk through it, Finder (an app running as the logged-in user) won't be able to read its contents and that's the bug. Finder has no idea what's mounted.

Fix: as root:

<pre class="ip-ubbcode-code-pre">chmod 1777 /Volumes</pre>
and rerun the ls to verify your fix.


Here comes a description of how mounts work in Un*x OSes and another possible cause...

You need two things for a mount: a file-system (on a local disk volume or network-served) and a directory on which to mount it (called the "mount-point"). The mount-point directory must pre-exist, at which point

mount file-system /path/to/mount-point

causes references to the /path/to/mountpoint/ directory to be switched from its parent disk to the "root directory of the mounted file-system". User access to file paths below the mount-point directory proceed seamlessly down the mounted file-system's hierarchy.

A. Some Un*x OSes make the transition to the root of the mounted file-system without evaluating permissions of the underlying directory (on the parent file-system) on which it's mounted. This used to be the case on all of the Unices I toyed with.

B. At some point or from a branch of Un*x I wasn't familiar with in the old days, access to the root of the mounted file-system switched to being gated first of all on the permissions of the underlying mount-point directory, then on the permissions of the root directory of the mounted file-system after that.

So here's a theory: If, underneath the mounted file-systems, their mount-point directories have user, group, and filemode settings which don't allow your "admin" accounts to execute them, accounts in group "admin" won't be able to traverse to the root of the mounted file-system.

The hard part is to examine the directory underneath the mount point. I'd say log into the system as root when no one else is using it, hop into Terminal, manually unmount the volume (eg. umount /Volumes/Data and then, if umount complains that it's in use, umount -f /Volumes/Data which cancels all programs accessing it, then unmounts it), then use ls -l /Volumes to see what the permissions are of the mount-point directory. eg. for /Volumes/Data:

<pre class="ip-ubbcode-code-pre">umount /Volumes/Data
ls -l /Volumes
mount /Volumes/Data</pre>
and locate the the permissions for Data, or to get directly to the specific listing of /Volumes/Data, you could

<pre class="ip-ubbcode-code-pre">ls -ld /Volumes/Data</pre>
while it's unmounted.

Do the permissions make sense?

If not, then something may be haywire with the startup scripts which carry out mounting all disks. These scripts actually create the mount-point directories under /Volumes (via the mkdir command) prior to issuing each mount. If they're not making globally-accessible directories, it's a bug in the startup scripts.


Note 1: The automount daemon will mount a user's NFS home directory if you're set up for that, but that doesn't apply to local mounts. Also, those automounted NFS mounts, once referenced, stick around until explicitly umounted, as when the shutdown scripts run.

Note 2: It's barely conceivable that some fancy config option allows for local volumes to be mounted at login and dismounted at logout of specific accounts, but again I've never heard of such a thing.



[This message was edited by Jazzbo on Sat October 11, 2003 PT at 8:28.]

10-11-2003, 11:24 AM
Ha! I was callin' ya with my brain... http://forums.macgurus.com/infopop/emoticons/icon_smile.gif

By not mounting I mean yes, not showing up in the finder... but also:

1)The drive and both partitions are visible but "grayed out" in Disk Utility, and the "mount volume" option is available in the pull down menu, but does not work (nothing happens). I can "check" or "repair" the drive, which apprears to work on both voumes, and reports they are "OK".

2) In ASP, both HDs are visible, but there is no volume info for the second, non-mounting drive.

3) The user and group management app - Workgroup Manager - does not see the two volumes (for AFP and SMBA), which are (were) sharepoints.

Oh, and I forgot to mention earlier - when the desktop loads after a reboot I get a system warning: You have inserted a disk that is unrecognizable... etc., with only an "Ignore" button. As if the OS can can see it, but not read it... except of coarse when I boot/login as root, then no warning, all drives mount, and everything seems AOK.

Did not attempt anything in the terminal yet, usually my last option http://forums.macgurus.com/infopop/emoticons/icon_redface.gif

I will reread your post, and may be able to get at the machine over the weekend, but maybe not before Monday...

THANK YOU for your support!
Put it on my tab... how will I ever repay the Gurus?


Anybody think this has anything to do with the drive? Does not seem like it, but I don't pretend to know the ins-and-outs of HDs, HD drivers, and such things.

The fact that the FW drive and RAM disk also acted strange took my attention elseware: OS.


Charlie Don't Surf!

10-11-2003, 12:12 PM
Sounds like OS X's buggy disk arbitration (but is that part of IOKit kext or the partitions OS X creates and uses?). The folks at SoftRAID complain that there are problems with the "plumbing" at this stage of the game.

SoftRAID doesn't use Apple partition scheme, which has meant that they aren't bootable for now, but might avoid problems and be more robust, too.

I'm sure you can display the partition tables, for what help that is, from terminal. ATTO ExpressStripe gives you a graphic view of the drives and volumes (making it easier for me to identify the name/number of each drive and volume).

10.0 provided for reinstalling. Now, if you want to refresh the system, you use the combined updater to hopefully repair or restore the system to how Apple wanted it.

10-11-2003, 11:29 PM
Hi TZ,

I just turned in a PO before this happend for SR 3, now that it has been on the scene a while and all reports I have seen have been positive...

Weighing the pros and cons: If I tranfer all data from drive/volumes in question to a pair of shiny new SATA drives (SR 3 mirrored) *could* that add too many varibles? Makes me nervous; new drives, and new SATA controller, and SR 3?

None of which I have used yet... Playing with fire?

I don't mind some risk, I'll just have to make about 4 seperate backups before I march forward with new hardware... http://forums.macgurus.com/infopop/emoticons/icon_frown.gif


Charlie Don't Surf!

10-12-2003, 05:55 AM

I'd take up the thread on SATA in your case to another forum, thread.

If you are still using PATA drives, SATA is one option (poor man's scsi) but I wouldn't do it NOW.

In fact, I wouldn't recommend SATA and SR3 if you have a project (video, scientific) that runs for hours (overnight operations) with a lot of intense disk activity. I remember when, say, doing airflow wing design calculations would require a full week of computer time.

Too bleeding edge. Make sure the swimming pool is FULL before diving in!

10-12-2003, 07:39 AM

Let's go over here (http://forums.macgurus.com/6/ubb.x?a=tpc&s=40160367&f=44660839&m=797600014&r=150603014#150603014) to kick around hardware that is seperate (I hope) from this issue.


Charlie Don't Surf!

10-13-2003, 01:42 PM
...This problem beating me.

OK Jazz, from the terminal, logged in as root:

"ls -ld /Volumes" returns "drwxrwxrwt 3 root wheel", so things are OK, yes? And no change: volunes mount when I reboot/log in as root, but not as admin.

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR> These scripts actually create the mount-point directories under /Volumes (via the mkdir command) prior to issuing each mount. If they're not making globally-accessible directories, it's a bug in the startup scripts.

Have not checked this yet, but if it is the bug you mentioned, what's the fix? Reinstall?


Here's where it get's more crazy. At some point, the internal CD ROM (OEM Lite-on combo drive) stopped mounting! I used it on Friday to run DW 3, but now no CDs mount in the Finder, including a factory 10.2.3 Disc. Tried booting to CD by holding down the "C" key, and it booted back the the HD....

Just for grins I performed an Open Firmware reset - no change.

Through about a dozen reboots, all stayed the same: root = mount, admin = no mount

Still stumped: what would cause internal slaved ATA, external FW, RAM disk, and now interal CD not to mount???

I also repaired permissions again, really just to see what would happen. No change, but here are the results, just in case it lends a clue:

2003-10-13 13:10:43 -0700 - Repair of privileges has started
We are using special permissions for the file or directory ./System/Library/Filesystems/hfs.fs/hfs.util. New permissions are 33261
Permissions differ on ./System/Library/ServerSetup/Configured, should be drwxrwxr-x , they are drwxrwx---
Owner and group corrected on ./System/Library/ServerSetup/Configured
Permissions corrected on ./System/Library/ServerSetup/Configured
Permissions differ on ./System/Library/ServerSetup/UnConfigured, should be drwxrwxr-x , they are drwxrwx---
Owner and group corrected on ./System/Library/ServerSetup/UnConfigured
Permissions corrected on ./System/Library/ServerSetup/UnConfigured
User differs on ./private/var/db/locate.database, should be 0, owner is -2
Permissions differ on ./private/var/db/locate.database, should be -rw-r--r-- , they are -r--r--r--
Owner and group corrected on ./private/var/db/locate.database
Permissions corrected on ./private/var/db/locate.database
Group differs on ./private/var/run/utmp, should be 0, group is 1
Owner and group corrected on ./private/var/run/utmp
Permissions corrected on ./private/var/run/utmp
User differs on ., should be 0, owner is 502
Group differs on ., should be 80, group is 20
Owner and group corrected on .
Permissions corrected on .
2003-10-13 13:15:24 -0700 - The privileges have been repaired on the selected volume.

I have noticed that the permissions on the boot drive do not stick (in the Get Info box using the Finder). Again today - at least the third time since I began looking - the "Owner" was set to System (I had expected it would be set to the original Admin), and the "Group" was blank.

Currently backing up everything to tape. http://forums.macgurus.com/infopop/emoticons/icon_frown.gif

Trying to decide if I should risk attempting upgrading to 10.2.8, as there is only so much I can really do in the terminal - even with remote access to bits of Jazzbo's brain (thanks!), but that could actaully make it worse. Everything seems to be working fine, as long as I log in as root...but it makes me very nervous not having actually solved the problem.

If I upgrade, and things go badly, I can always reinstall from CD and upgrade back to 10.2.6 (.5?). I would have to reinstall anyway if I wanted to go back to 10.2.5, so not *that* big of risk. Have to think about it for a while....

What about a virus, trojan, etc? Last I heard there are none for OS 10, but anything out there that for Unix that *might* hit an OS 10 box???


Charlie Don't Surf!

[This message was edited by unclemac on Mon October 13, 2003 PT at 14:52.]

10-13-2003, 07:47 PM
Hiya, Uncle Mac,

Yessir, the permissions on the /Volumes directory as you found them are correct and not the blocker.

In the output of the repairing permissions, though:

1. hfs.util

<pre class="ip-ubbcode-code-pre">We are using special permissions for the file or directory ./System/Library/Filesystems/hfs.fs/hfs.util. New permissions are 33261</pre>
is ridiculous. '33261' as a filemode ("permissions") doesn't mean anything. Please run

<pre class="ip-ubbcode-code-pre">ls -ld /System/Library/Filesystems/hfs.fs/hfs.util</pre>
and post the output back. Merely by its filename (an "HFS utility"??) one wonders if screwy permissions on it could be a blocker in the arena of discovering what HFS volumes are mounted (or mounting them anew).

Permissions on mine look (appropriately):

<pre class="ip-ubbcode-code-pre">-rwxr-xr-x 1 root wheel 43716 Oct 4 13:53 /System/Library/Filesystems/hfs.fs/hfs.util</pre>
To match that (as root):

<pre class="ip-ubbcode-code-pre">chown root:wheel /System/Library/Filesystems/hfs.fs/hfs.util
chmod 755/System/Library/Filesystems/hfs.fs/hfs.util
ls -ld /System/Library/Filesystems/hfs.fs/hfs.util</pre>
(the last step to check your work).

2. The ServerSetup directories

The "Configured" and "UnConfigured" directories complaints are

<pre class="ip-ubbcode-code-pre">should be drwxrwxr-x , they are drwxrwx---</pre>
which means that no one other than the owner and users in whatever group those files have can access them at all, pre-repair and assuming the repairing program actually fixed them.

I don't know what these directories are for. Run these two commands, please,

<pre class="ip-ubbcode-code-pre">ls -ld /System/Library/ServerSetup/Configured
ls -ld /System/Library/ServerSetup/UnConfigured</pre>
and verify that the permissions strings at the beginnings are drwxrwxr-x,

3. locate.database

User should be 0, is -2. User 0 is root; "-2" is the "nobody" user.

I'm not sure what /var/db/locate.database is, but I guess it's used by the lookupd to cache NetInfo and DNS entries. Mine seems to run fine with permissions -r--r--r-- and owned by "nobody", and I doubt this file plays into your problem.

4. /var/run/utmp

Group should be 0, is 1. Well, group 0 (nidump group .) is "wheel" and group 1 is "daemon". Nothing serious here.

5. /

Yep, it's going after your root directory, and reporting it as . (dot).

The owner is 502, group is 80; should be owned by 0, group 20.

Well, uid number 502 is, by convention, the second assigned when you create accounts (nidump passwd . and look for the entry with 502 as field 3 to know which account has that uid number).

Group 80 is 'admin' and group 20 is 'staff'.

My guess is that ls -ld / will now report

<pre class="ip-ubbcode-code-pre">drwxrwxr-x 1 root staff 1360 Oct 4 13:53 /</pre>
This is/was most definitely not the problem or users wouldn't be able to login at all.

Side note on those permissions for the root directory:

If you run a stock SMTP server on these OS X machines (10.1 and 10.2) and have group-write enabled as per repairPermissions, /usr/sbin/sendmail (which is both the SMTP listener and the injector for new mail messages) will distrust its configuration directory (/etc/mail), complaining that "A directory on the path to sendmail.cf is group-writable". I've also seen one machine with a globally-writable root directory (drwxrwxrwx) and, needless to say, sendmail didn't like that one bit. Fix? chmod go-w / to turn off group and other write access to your root directory, and do that every time you "repair" (and thus break) permissions.


[This message was edited by Jazzbo on Mon October 13, 2003 PT at 21:00.]

[This message was edited by Jazzbo on Mon October 13, 2003 PT at 21:01.]

10-14-2003, 09:00 AM
You guys are so over my head and into this, but I say this on

MacOSXHints (http://www.macosxhints.com)

"When backing up my "Home" directory before upgrading to a new hard-drive, I was unaware of the various Unix permissions that had to be conserved, in order to do this successfully. When reinstalling this backup into my newly reinstalled OS X 10.2.8 system folder on my new hard-drive, I found that most of my files and many of my applications were unusable. I had copied the backed up files using the Root account, and apparently this had changed all the permissions such that the files were now owned by Root, not by me!

A bit of frantic Unix research on a local Mac bulletin board followed (Revelation BBS, in Vancouver BC), where I found a tip contributed by Derek M. Warren, who came up with the following. This has (apparently) worked to restore full usability to my entire "Home" folder and files. In the Terminal app, type:

% sudo su
% chown -R myname /Users/myname

The first line gives you root level access; the second line restores the correct ownership of the home folder. Replace myname with your actual short username, of course.

This seemed to work okay (fingers crossed!)

robg adds: Some things to keep in mind -- Carbon Copy Cloner will create backups with permissions intact, and you might also be able to recover from something like this by running Apple's Restore Permissions (in Disk Utility), though I'm not sure it looks at ownership of the Users folder.


[This message was edited by TZ on Tue October 14, 2003 PT at 10:11.]

10-14-2003, 10:03 AM
Over your head...

Jeeze, howda think I feel? http://forums.macgurus.com/infopop/emoticons/icon_eek.gif


Thanks though for the info, just digging in on this today.

Oh yeah, and an update from yesterday afternoon:

While digging through in Workgroup Mangager, I noticed that two the files that are unique/visible to WM on server - the "VolumesSettingFolder", and the "Volumes" folder were set to a non-admin user as owner, and no Group! No way I did that, and not sure what they should be set to. I never messed with any stuff outside of the users I set up, and their stuff; these are OS files.

Getting ready to install Server on another G4 just as a test so I can compare a fresh install to what I have going now...

First I will get started on Jazz's instructions.

Charlie Don't Surf!

[This message was edited by unclemac on Tue October 14, 2003 PT at 11:21.]

10-14-2003, 10:46 AM
Here we go J -


[Central:~] root# ls -ld /System/Library/Filesystems/hfs.fs/hfs.util
-rwxr-xr-x 1 root wheel 43716 Mar 18 2003 /System/Library/Filesystems/hfs.fs/hfs.util

and then:

[Central:~] root# chown root:wheel /System/Library/Filesystems/hfs.fs/hfs.util

[Central:~] root# chmod 755/System/Library/Filesystems/hfs.fs/hfs.u

[Central:~] root# chmod 755/System/Library/Filesystems/hfs.fs/hfs.util
usage: chmod [-R [-H | -L | -P]] mode file ...

[Central:~] root# ls -ld /System/Library/Filesystems/hfs.fs/hfs.uti

[Central:~] root# ls -ld /System/Library/Filesystems/hfs.fs/hfs.util -rwxr-xr-x 1 root wheel 43716 Mar 18 2003 /System/Library/Filesystems/hfs.fs/hfs.util


[Central:~] root# ls -ld /System/Library/ServerSetup/Configured drwxrwxr-x 3 root admin 102 Jan 17 2003 /System/Library/ServerSetup/Configured

[Central:~] root# ls -ld /System/Library/ServerSetup/UnConfigured


Charlie Don't Surf!

[This message was edited by unclemac on Tue October 14, 2003 PT at 14:32.]

10-14-2003, 12:04 PM
So here is current status...

After performaning commands as per last post, no real change. Noticed this - perhaps a clue:

I reboot, login as root, mystery volumes mount.

I logout and login as admin, mystery volumes don't mount.

I logout and login as root, mystery volumes don't mount.

I reboot, and log in as root, mystery volumes mount.


Something tied to startup procedure, that does not run with a login/logout. So when I login as admin, I kill acccess even for root, and only a reboot will restore... maybe a clue?

Just finished installing 10.2.6 Server on a backup G4, going to see if I can compare some of the file permissions.


Charlie Don't Surf!

[This message was edited by unclemac on Tue October 14, 2003 PT at 14:35.]

10-14-2003, 02:10 PM
I KNOW I read a thread on bbs.xlr8yourmac.com about someone having these mystery volume problems. 3 months ago, maybe less.

Looking for something in the "/Volumes" directory or a syblink or link to a volume that is no longer present????

10-14-2003, 02:52 PM

Great article. Top Ten Unix Tips.
Terminal App and Unix link on left.

There's always a need to pick up a few pointers. Or books.

10-14-2003, 05:51 PM
I've been thinking over this "no group whatsoever. Blank." and the "no admin group in the list" bits from your original post (and the more recent reference). Then, that clicked in with removing admin privs for a user. A brandy-new possibility!

Just suppose that instead of removing "admin" privs for a user -- which would change the user's group affiliation away from group 80 (admin) to something else -- that the entry defining group 80 was deleted from the group tables.

Belaboring the semi-conscious horse, the group number is what's stored on-disk to show file group affiliation. The group number is what's read from the passwd (accounts) table to see what a user's primary group is. The group number is cross-referenced through the group table to come up with its name (or the other way around, if you know the name and need to find out its number).

If the group table from the NetInfo database no longer had an entry associating group number 80 with the name "admin", it wouldn't show up on selector lists.

Try this:

<pre class="ip-ubbcode-code-pre">nidump group .</pre>
and see if there's an entry for the admin group (field one) relating it to gid number 80 (field 3).

There's a second group table, used only during the boot process until the lookupd is launched to serve the table from NetInfo. Do this:

<pre class="ip-ubbcode-code-pre">cat /etc/group</pre>
and see if the entry for the admin group is present in this file.


When you're doing the inspection and see "no group affilated with __fill_it_in__", how are you examining it? Command-I in Finder? Try this instead:

<pre class="ip-ubbcode-code-pre">ls -ld __drag_n_drop_the_thingy_from_Finder__</pre>
and see if, in the "group" field (fourth, just after the owning username) there's a number instead of a group name. That'd put it on ice that the entry giving a name to that group-id number is missing from your NetInfo group table.


If the admin group is missing from your NetInfo db, I think I can coach you through re-adding it via /Applications/Utilities/NetInfo Manager. It's even easier to get it back into the /etc/group file that's used prior to lookupd getting launched.


10-14-2003, 10:10 PM
Here ya go:

"nidump group ." returns the following(matt = admin user):

staff:*:20:root(...and complete list of users...)


And "cat /etc/group" returns the following:



I edited out the user groups that I thought were not relavant - let me know if something is missing that might need to be verified...

Question: Should "admin" in the second group (or any other user/group for that matter) also include the actual admin user (matt)?

Thanks Jazz!

[This message was edited by unclemac on Tue October 14, 2003 PT at 23:21.]

10-14-2003, 10:40 PM
OK. For the drag and drop trick, keep in mind it's the boot drive Server is running on, so I get this:

ls -ld /
drwxrwxr-x 37 root admin 1258 Oct 15 19:34 /

Is that what you expected to see?



"...and see if, in the "group" field (fourth, just after the owning username) there's a number instead of a group name."

...not sure where to look; lost me on this. http://forums.macgurus.com/infopop/emoticons/icon_frown.gif


And just because I was curious, here are the two mystery volumes, dragged and dropped:

[Central:~] root# ls -ld /Volumes/IT\ Dept
drwxrwxr-x 20 matt IT Group 680 Oct 13 15:20 /Volumes/IT Dept

[Central:~] root# ls -ld /Volumes/Marketing\ Dept
drwxrwxr-x 50 matt Marketin 1700 Oct 9 16:13 /Volumes/Marketing Dept

[This message was edited by unclemac on Wed October 15, 2003 PT at 9:31.]

10-15-2003, 09:49 AM
Jazzbo's thoughts got me to thinking about NetInfo...

So while looking around - no touchy! - I came across this, which looks odd, although I have no idea what it *should* be.

When I click on /mounts, this is the detail in the lower half of the window:

name_________***not a UTF8 string***
opts_________(net,url==afp://;AUTH=NO%20USER%20AUTHENT@ Public)

Very strange.... What't that IP all about?

The IP scheme fits our internal private block, but this box is on a 216 block, and *nothing* is on the IP listed, so no idea where that is coming from. Found out that "UTF8" has to do with text/font/language stuff, so perhaps not related...

But, hello, what do we have here!?

/users/matt had this info:


And all the other uses I have checked so far have the same.


What the heck does that mean? And even if this is seriously screwed up, is it even part of the volume mounting issue?


[This message was edited by unclemac on Wed October 15, 2003 PT at 10:59.]

10-17-2003, 08:37 AM
Your group tables, at least so far as the admin group is concerned, are fine.

The on-disk one, /etc/group, is only used until the lookupd is running -- you've seen "Starting lookupd..." in the bootup window -- after which only the NetInfo group table is used. That's why the on-disk /etc/group table only has minimal and system-standard entries; just those needed to get the bootup programs launched up to having lookupd accessible.

[I approve of your edits to chop values you shouldn't expose on the 'net.]


With regard to the ls (list files) command, the options we're using are:

-l give me a long listing

-d if the thing we're listing is a directory, tell me about it, not the files it contains

So, ls -ld / means "Give me a long listing of the root directory, itself." Try it without the 'd' option and see what you get.

Your output was:

drwxrwxr-x 37 root admin 1258 Oct 15 19:34 /

Reading the fields left to right we get:

1. filemode (one-char special type indicator, d=directory, followed by three-char permissions for owning user, group, and others)

2. number of links (for a directory, it appears to be the number of files it contains plus 1, and I don't know why)

3. owning user

4. group assignment (what we were looking for, and 'admin' is correct)

5. size in bytes (a directory is just a file of a special type, and it grows as needed to store entries for the things inside it)

6-8. last modification date/time

9. filename

So what we were checking was that the filemode allowed appropriate access (it does) and that the group was either staff or admin (it is), so the root directory's okay.


You (matt) own the two volumes you listed. One is writable by your IT Group, the other by Marketing, and in each case, anyone not in the associated group can read and traverse into the volumes, but not write them.

Nothing wrong there!


So with all the ls commands and checkings of the group tables, I don't see anything there to lead into a wilderness of disappearing volumes.


10-17-2003, 09:45 AM
I have a Server installation at work I can examine to see about the NetInfo mounts and users entries you described (need to remember that on Monday!), but the gist of entries like those suggest AFP-served "Public" folders in the first case and auto-mounted home directories in the second.

In other words, if we rip up the entry under mounts:

<pre class="ip-ubbcode-code-pre">vfstype______url
name_________***not a UTF8 string***
opts_________(net,url==afp://;AUTH=NO%20USER%20AUTHENT@ Public)</pre>
1. identify the file-system type by a URL (as opposed to?? I dunno!)

2. it's to be mounted under /Network/Servers (not /Volumes) (* see below)

3. the name isn't a printable string -- perhaps because we don't know what it is until one is requested?

4. Inside options, we're getting it from the network (as opposed to a local disk) and here's the URL specification answering the file-system type assignment in the first entry.

The URL kinda looks to me like "If you want a user's Public folder, mount using AFP for guest access (no user authentication on the AFP connection), and request the user's Public folder mount", assuming you plugged the username in between the last / and Public.


Now let's break up the users entry:

<pre class="ip-ubbcode-code-pre">home_loc_____'&lt;home_dir&gt;&lt;url&gt;afp://;/url&gt;&lt;path&gt;matt&lt;/path&gt;&lt;/home_dir&gt;'</pre>
This one is defined in XML with nested tags. We're going to make an AFP connection to and request a mount of /Users from it, then travel into its matt subdirectory as your home directory. I think.


(*) The /Network/Servers directory is used as a stock location to put network mounts, and the next level down is generally the hostname of the server. For example, I might have an NFS (better for this than AFP) served network home directory that comes from a server named brass. If I log onto a host equiped for it, I should magically find that my Home is


The mount-point is 'tuba', the exported volume from the server 'brass'. My home directory is the directory 'jazzbo' inside the 'tuba' directory.

Examining the contents of the 'tuba' directory will yield other users who also have their home directories on the 'tuba' volume from the server 'brass'. Pop up one more level and I'll see what other volumes are network-served from brass, perhaps 'trumpet', 'horn', and 'trombone', holding other users.

Need more than one home-directory server? Cobble in servers named 'strings' and 'woodwinds' with volumes whose names you can imagine and a very large corporation starts having generic OS X hosts scattered all over the place. Log into any NetInfo-connected OS X and you have your standard, non-admin desktop at hand.

With auto-mounting you can also serve out global (or grouped) tools, source repositories, reference libs, and so on, auto-mounted under /Network/Servers on the users' machines on demand when they reference them.

To do these sorts of things, you need a master (root) NetInfo domain and, if you need groups of machines, group-named NetInfo subdomains, deployed across your whole net. Any machine affiliated with one of the NetInfo subdomains has three NetInfo structures in play:

. (aka. local) -- the only one we've played with so far, on "this host" only
subdomain-named -- your group's subdomain tables, inherited onto your system
root -- the master for the the whole net, inherited onto your system

If the corporation (or school or whatever) net isn't big enough to require NetInfo subdomains, each machine will only have two NetInfo layers (local and root).

Deploying a root NetInfo domain is 'way powerful, especially when combined with NFS-served home directories. I have a hard time imagining running a moderate (say, 50 person) Unix-based shop without auto-mounted home directories, let alone something big. It also allows you to focus all your backup/restore needs on the NFS servers, as other than individual users customizing their desktop systems, corporate assets are all on those central servers.



[This message was edited by Jazzbo on Fri October 17, 2003 PT at 11:07.]

10-17-2003, 10:56 AM
Just a thought, but I've never seen group-names with spaces in them. Like your "IT Group" groupname.

Programs being what they are, it's possible that some code knows how to handle multi-word groupnames and others don't -- that is, they "know" they're looking for a single word.

Something you might try is to change the name of that group so it's just a single word ('itgroup', for instance). Then logout and log back in to see what happens.

Also, most of the time, usernames and groupnames are in all lowercase. That can matter on OS X, HFS file-systems, for instance, can get confused by two files with names identical other than case (eg. 123.jpg and 123.JPG).

If you're not clear on how to rename a group, let me know. I know how to do it non-Server or via NetInfo, but not exactly sure how it's done with Server's management tool.


10-17-2003, 01:26 PM
Wow. As always, thanks for loaning out your amazing skills...

I hear ya on the naming convention issues, except they have always worked fine in the past, so seems doubtful in my simple universe that they are the cause.

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR> Deploying a root NetInfo domain is 'way powerful, especially when combined with NFS-served home directories. I have a hard time imagining running a moderate (say, 50 person) Unix-based shop without auto-mounted home directories <HR></BLOCKQUOTE>

I would love to proceed with setting this up in the next few months. Merely a matter of execution....

Oh, and although we do have something like 70 users with accounts on this box, we are a Mac (and some Wintel) business; very low tech users for the most part. Fond a big shiny buttons, dancing paper clips and the like.

I am getting ready to pull the plug on this project, but everything (such that it is) works while logged in as root.

After installing server on a different volume I realized that there is no obvious way to move/import users and groups, and data without trashing permissions. No slower and less risk just starting over and building fresh. Going to think about that for a while....

Saw this (http://docs.info.apple.com/article.html?artnum=107210), and some nuggets for us GUI types here (http://docs.info.apple.com/article.html?artnum=106712), but no golden bullet - yet.


Another clue pointing towards permissions problem down deep (to me anyway...) in the OS:

I used CCC to clone the drive, booted from the clone, updated to 10.2.8, and no change. If I boot to the cloned/updated volume, and log in as matt, I can't see any other volume, including the drive I just cloned and booted from.

Assuming that the problem was cloned, it is now very repeatable that if I log in as matt, I cannot see any other volume/drive. If I log in as root, I can see all volumes and drives (master/slave ATA and firewire), except the CD ROM. Never see that, but can boot to it fine.

What hurts my head is that from all I have read, admin (matt) on server is root!

So root is not root???



I think I will most likely end up rebuilding users and groups from scratch in order to clean up naming convention problems, and generally get my shit wired tight. I think I can do it all offline and then CCC it back to the server box, and then import data from old to new.

I can tell you are a sucker for a mystery http://forums.macgurus.com/infopop/emoticons/icon_razz.gif , thank the gods for my sake, but please don't kill yourself on this on my behalf. I am sure I used up too much of your time already...


And thanks for your support as well TZ, always happy to have it!


Charlie Don't Surf!

10-21-2003, 07:24 AM
I was doing some reading last night, "Mac OS X PowerTools" and "Mac OS X in a Nutshell." Nutshell is right :-)

I think Nutshell is the type of boot a sysadmin wants to have handy. Gets into the guts, commands, scripts, terminal, netinfo manager, the works. $35 from O'Reilly.

10-21-2003, 07:40 AM
Thanks for the tip. I was digging through Unix Powertools, but WAY out of my league.

...Those are the kind of power tools that could cause a massive amputation or even decapitation for a novice! http://forums.macgurus.com/infopop/emoticons/icon_eek.gif

Next thing I want to look at is moving users and "shared items" on Server; have not even started to look yet. Not sure what it will take (or if it is even possible) so that the Workgroup Manager app will "see" everything after being moved to a differnt volume...

This would be a wonderful help to really manage Server, regardless of the current problem.


Charlie Don't Surf!