[taco]

I sorta fixed it the cowboy way.

I made two AppleScripts that work when root or user 0 is logged in. The first script copies the contents of the chosen Home folder to /var/root/Desktop. The second AppleScript will create a new folder in /Users/ and deposit the contents of /var/root/desktop to the new folder at /Users. and chown rights to the name of the new folder. When you login again as the new user for the first time, Mac OS assumes the new ID is you and goes its merry way.

There has to be a better way, but this will do for now. I have tested the method both in Tiger and Leopard successfully.

——————
[b]Script 01[/b]

with timeout of 1800 seconds
set dialog1 to choose folder “Choose Home folder to move.”
set B to POSIX path of dialog1
set script1 to “sudo cp -rf ” & B & ” /var/root/Desktop”
tell application “Terminal”
activate
do script script1
end tell
end timeout

——————
[b]Script 02[/b]

set dialog1 to display dialog “Name of new home Folder.” default answer “”
set newfldr to text returned of dialog1
do shell script “mkdir /users/” & newfldr
tell application “Terminal”
activate
do script “cp -r /var/root/Desktop/ /users/” & newfldr & “/;chown -R ” & newfldr & ” /users/” & newfldr
end tell

[taco]

I got some more information to help explain my question.
This morning, my XServes were getting swamped by the sofwareupdate process again.
I went to TOP in terminal, found the PID and catted it out to a text file –

PID TT STAT TIME COMMAND
25009 ?? Ss 707:30.42 softwareupdate -q -l -f /private/var/run/SoftwareUpdateStatus.plist

Utilization was running at anywhere from 80-95 percent.
I then went on the trail and found the plist file.

Here it is –


date
2009-04-30T18:40:11Z
phase
SCANNING
phaseStatus
INPROGRESS
pid
25009

So the softwareupdate thing may be stuck searching for things to update and just sits hogging my XServe’s CPU.

What would be the safest way to prevent this from occurring? Both XServes are used in a heavy production and they have to be at their best performance at all times.

Info on XServes –
10.5.6 Server
G5 duals
Bound to AD
Services running –
AFP, SMB

[taco]

I’ve see those log entries before. Before I went totally AD on the XServe, it was an ODM sharing SAMBA. Folks would tell me they could not browse for it in the Network Neighborhood. They connected using \\server domain name. But it never dropped SMB/CIFS connections.

Does it have a fully qualified Domain name?
It’s Time/Date is in sync with an enterprise- wide NTP service?
Check your kerb principals.
Is it a Domain Member under Server Admin.

[taco]

Update –

For some reason the group I was using from local was not working with AD UIDs. This group had exclusive access to Share X. So I went back into my OU, under AD on a PC and created a fresh group, and assigned it to Share X.

So far AFP is responding favorably.

The ‘Why’ is another matter.

I suppose persitance and determination are the best medicine when dealing with issues of this type. And the fact that just because one thing is showing weird behaviors does not mean that you should redo the entire server. Working non evasivly towards a solution is the first and best policy.

[taco]

Today, in a preemptive move, I went to IT and asked them to remove the user from our group that I use to give everyone access to the share — then add him back to the same AD group. They have the power to refresh the AD and I don’t so I thought this would help. I did the id command in the Terminal 2 hours after this request on a Mac OS 10.3.9 Mac, a Mac OS 10.4.8 Mac and the XServe. All did not show that the user had been added to the needed group for my XServe share. But WGM showed the user WAS a member of the group. This afternoon the user emailed me AGAIN saying he could not get into folder X under the parent share. He could see folders under the parent share, but when he wanted to go to the folder X, he saw nothing. The folder had restricted access — Admin – rw, AD Group- rw, and Everyone – no access. I heard that making a local XServe group from AD UIDs was a possible troubleshooting method. So I killed the AD group in my OU that had special access to folder X, then created a local group on the XServe and populated it with the AD users. I was one of the users to add to the new local group. In WGM I then used Effective Permissions Inspector to confirm the user had the proper access. It checked out. I logged in to my eMAc and could see the contents of folder X. I went to his desk, asked him to restart his eMac. He logged in (AFP) and navigated to folder X – NOTHING. This whacked me out! I then decided to move the folder from the parent folder (that was the share point) and move it to the XServe RAID root directory as its own share. I thought this might kill any influence the original share point was having to the user’s rights. I shared folder X AFP, SMB only with no guest access. I again checked the user’s permissions using EPI – he checked out. On his eMac this time (AFP) the same result – NOTHING.

I saw his PC laptop on his desk and asked him to log in to see if he could see the contents of the new share. BOOM! He could browse share X!!

What the 😈 ??

[taco]

[QUOTE][u]Quote by: taco[/u]
I read about something that when a user is assigned to 16 or more AD groups, Mac OS X Server goes ga ga.
I’m going to count the groups this users has and report that here.
[/QUOTE]

The Mac user in question currenlty belongs to 23 AD groups.
I found others with the same number who have yet to make a complaint. This user is ‘cursed.’
😡

[taco]

I use the id command in BASH. Tells me what groups the user is a member of. I see GIDs too. One user at a time, but useful to me.

Example –

G5:~ taco$ id mysql
uid=74(mysql) gid=74(mysql) groups=74(mysql)
G5:~ pha1$

Hope this helps.

[taco]

My experience has been that it won’t let you mix local/AD users into a local group. I tested on my test server and like you I could get the share to mount, but could not see the contents of the share.

[Author]

Posts