I donwloaded something called osxutils, which contains a handy command called mkalias which, if manually done, allows me to create an alias of the home folder into my profile.

Ill try and explain this as best I can.
if i login as the AD user called "mediauser", the machine is setup to create the profile locally, so it creates /Users/mediauser and stores their profile in there.
If i use this mkalias cmd, I can run it in a terminal...

mkalias /volumes/Personal$/mediauser Homefolder

this creates an alias in the profile called "Homefolder" which points at the users home folder stored up on the windows 2003 server, which will now allow the user to save into their home folder when using the likes of word or photoshop by clicking file -> save as and browsing to the alias called "HomeFolder"

Only problem now (Still) is that if i try to put this into a loginhook, i still cant get it working so that I can identify who is currently logged on and append it to the mkalias cmd...
i.e.

USER = ??
mkalias /volumes/Personal$/$USER Homefolder

Ive tried using $LOGNAME, $USER, whoami, but all return either root, nothing, and sometimes even .spotlight (or something like that).
you'd think this was the easy bit!

Dude, that is easy. Whatever user is logged in, always owns the console. So you can easily see which user it is, by doing this:

my results:

bash-3.2# ls -l /dev/console | awk '{ print $3}'
tlarkin


So, just set a variable for that command and then call it to map that specific user. This is because all log in hooks are ran by root, and not by a specific user. So root is always going to own the log in hook no matter what.

this might sound like a stupid question, but how would i get this to run if i dont set it as a login hook?

as you mentioned, running a script as a login hook will always run under the root user, so is there a way to have a script run on startup that doesnt run under the root user?

our preference is to have this setup in the background so any user who logs on, a script will run and create the alias

Use launchd and put the script in ~/Library/LaunchAgents and it will run when that user logs in, but I think this also runs as root. My method is pretty simple though and has worked out for me rather well.

I presume when you mention your method, is it just a case of running the command in the terminal window yourself?

Only problem with that is the environment Im looking after is a college, and even the mention of terminal will send them running!!

Well here is what I would do.

1) create a script that can either output the currently logged in user and have it execute with the commands you used to create the home folder alias with.

2) Create a launchd item and place it in /Library/LaunchAgents. Launch Agents will run any time any user logs in. You may want to create a loop with an if/then so if a local account logs in the script exits.

3) Copy out your launch agent plist and your script to every machine locally, or have Open Directory run it via MCX

4) use launchctl to permanently load it and now you have a working log in hook that runs under the hood with no user interaction. It just simply works.

cheers for that, ill give it a go later on and let you know how it goes.
We have a mac server that the clients are bind to (they are also bind to AD) so ill try run it via MCX

Can I ask a basic question please?

How would one go about setting a variable to the results of that awk command?

Thanks

OK, lets say you wanted to modify a plist file in that user's home folder, the one that is currently logged in. Since the currently logged in users, by design, owns the console we can take that knowledge and apply it to a variable like so:

example:
Since all log in hooks run as the root user you either have to full path it out to the user specifically you want to modify, or use the sudo -u command with the current user specified to run it as, so sudo -u tlarkin for example would run it as if the user tlarkin were running it.

Thanks Tlarkin but I managed to get it working this way :-

#!/bin/sh

me=$(ls -l /dev/console | awk '{print $3}')
mkalias /volumes/Staffusers/$me /Users/$me/Desktop/H_Drive

--------------------------------

This puts an alias of the user's folder on the desktop.

Awesome, glad it worked out for you.

The script works well during testing but fails in practice when logging in. I suspect it is because there are upwards of 2300 folders in the volume share and it can't parse the folder list in time. The system log simply says :-
volumes/staffvol/abc3 : no such file or directory.

If that diagnosis is correct, then perhaps making a symlink instead of a Finder alias would be better.
[i.e., instead of mkalias, use /bin/ln -s ]

BTW, why does the error say "volumes/staffvol/" while your code has "/volumes/Staffusers/" ?

Hey guys,

Why don't you replace $(ls -l /dev/console | awk '{print $3}') with $(whoami) since you're after the currently logged in user. Or if you're doing this in a loginhook the last time I checked loginhooks get passed the current user in $1.

// Tony

Log in hooks run as root user so whoami would return root. I am not sure if $1 returns the current user as a log in hook or not.

I just checked and if you add the script as a loginhook to loginwindow.plist then you definitely get the logged in user as $1. It's working in 10.4, 10.5 and 10.6

// Tony

OK, that is what I was going to get at, if you have the loginwindow.plist control it. I knew you could do that, but a lot of times I have launchd control it, WGM control it, or Casper control it. So I always see who owns the console, and do it that way. There are always many different ways to accomplish the same task.

thanks for sharing

I use other scripts that use $1 with no problem but it doesn't seem to work with this one. Using the "awk" thing to get the user, I added a loginhook but it still doesn't work despite working OK if you drag the script into a terminal window and press return!
Even though I am logging in as abc1, the system log now says :-

09/03/2010 14:22:16 com.apple.loginwindow[1224] /volumes/Studhome/root: No such file or directory

You are using full paths? Since Studhome is not a standard home directory path. Make sure your scripts always use full paths, and are you still getting issues?

Sorry don't understand. It is a full path. Inside the "share" studhome there are thousands of student folders, one of which is abc1. The studhome volume is automatically mounted on the desktop when AD users logon. Their home folder, quite uselessly (can't "save as" to it), is added to the dock.