WGM creates new home folders with _unknown user/group, SA can’t change it

[edufixitguy]

A little background:
In our school we’ve got an xserve (about 1.5 yrs old), that was having issues last year. (the OD database pretty much ate itself). in august we did a clean install of 10.5, and updated to 10.5.3 (after suffering through the AFP/OD issues in 10.5.2). Because of the corrupt database from the last server, and the fact that a large number of our accounts have migrated through 4-5 iterations of servers from 9.2 on through 10.4.11, we created all new clean accounts by hand in WGM and moved the user files to the new home folders, changed user and permissions with SA to the new accounts and propogated that info to all the files for each home folder. everything has been going fine since then.
until this week.
the issue was discovered when we tried to create a new staff account (we created several accounts last week with no issue). in WGM everything looked fine. it created the account, assigned it to the proper group, and sucessfully created a home folder. the problem however was when we went into SA to change the permissions. we don’t need everybody seeing everyone else’s files, so we change the default group and everyone permissions to something more appropriate (don’t even get me started on that gripe). When you navigate to the new home folder you just created in WGM, it shows the owner as _unknown (read/write) and group _unknown (read only… I think), Everyone (read only). Server Admin refuses to change the user or group. doesn’t matter whether you use the ‘show users/group’ dialog and drag the account, or whether you edit it manually and insert the short name or UID. when you hit save, it stubbornly reverts back to _unknown/_unknown for user and group. we’ve tried creating accounts with different templates, no template, different account names and UID’s, all with the same result.

The odd part is that nothing in the OS has changed since we first set it up and created all the users. nothing installed, nothing updated…
We’ve stayed at 10.5.3 due to the disaster in one of the updates (10.5.5 I think) that many of our other local districts had with network accounts not being able to see their own library folders due to permission issues, as well as the AFP causing 100% CPU use bug reported with 10.5.5

A second, probably related issue is that when browsing home folders in Server Admin filesharing, any files our network users create seem to end up assigned_unknown/_unknown for user and group (as far back as October it seems). After searching around the net most of the day I came across a lot of info about the _unknown user issues for folks upgrading from 10.4, but these are all newly created 10.5 network users (not local) logging in and working in home folders on the server. The original owners can read/write/delete these files as normal.

Any help would be most appreciated.

xserve Mac OS X (10.5.3)

[edufixitguy]

ok… I find we were shot in the foot by one of our own.

The quick answer: DO A GET INFO ON THE VOLUME WITH THE SHAREPOINTS! if the ‘ignore permissions on this volume’ box is checked… UNCHECK IT!

Explaination: not sure how the ignore permissions box got checked, but I don’t think it was done directly by human hands. we use Carbon Copy Cloner Ver. 3.something (not sure which at this point) to back up both our data (daily) and server (weekly) drives to remote storage. by striking coincidence, things started saving with _unknown user and group about the same time as crash reporter shows that CCC hosed itself. My guess is that CCC temporarily ignores permissions (as shown in the status when you do a clone) and then resets them to their original state. when it crashed, it looks like they were still set to ignore, so it happily set it back to that state every time it ran after that. not sure why the account creation issue suddenly turned up after so long… In any event, it turns out that if you have sharepoints on a server volume, AND you set the OS to ignore permissions on that volume, BAD things happen (I’m not sure it should even be an option on a shared volume, but that’s for the engineering folks to figure out.) …. specifically, the symptoms above. if you login as root (yeah, I know that’s something you should never do) and uncheck the ignore permissions box on the volume, then log into WGM, as root (yeah, yeah, I know… even worse) and set ALL of the Directory Administrator accounts to ‘do not administer this server’, and no change rights for the directory, save those settings, and then set them back to ‘administer this server’, and FULL rights to change the open directory, save again. and then WAIT until the drives stop going nuts… after that everything works fine.

[Author]

Posts