I see the key in the sidebarlists.plist file but I'm not sure how to disable it. At any rate, my boss made a very good point about this so I am not even pursuing the issue any more. If I were to remove the local home folder from the sidebar user's would have to know how to drill down through the users folder to get to their itunes, iweb and imovie libraries which they actually do save to the local hard drive.

He suggested that I rename the sidebar shortcut to "User's Local" or something like that but when researching how I discovered it is impossible to rename items in the sidebar. The only way to do it is to rename the original which would hose the user's profile. Even if you created an alias to the home folder and dropped it onto the sidebar it would resolve the original folder name. Oh well, it's not something I'm going to worry about too much, I'm very happy just to have the network home on the sidebar.

I dont really know what going wrong with out script, so im just going to throw this out there and explain it best i can...

firstly, we have had to go back to basics with our script as getting all sorts of problems when testing, so here it is...

#!/bin/sh
sleep 5
ls -l /dev/console | awk '{print $3}'
USER=$(ls -l /dev/console | awk '{print $3}')
echo 'Username is: '$USER
SMB=$(dscl /Active\ Directory/All\ Domains -read /Users/$USER SMBHome)
echo $SMB

when the user logs on, the console reports the following:

22/04/2010 12:20:51 login.plist[2427] Username is: xfinemedia
22/04/2010 12:20:51 login.plist[2427] SMBHome: \192.168.10.44\mactest\class02inemedia

the above is copied straight from the console, and its as if the dscl command is not returning the proper value.

If when logged on as the user xfinemedia, and i go into terminal and run dscl and query the SMBHome, i can see the value SMBHome: \192.168.10.44\mactest\class02\xfinemedia

anyone got any ideas???

not sure if this makes a difference, but ive tried this with a few test users, and for some reason, if the username begins with certain letters, it returns the proper home folder. i.e. i created a user called mediauser and it worked perfectly.

all the above users are in AD, the mac is binded to both AD and an Mac server in the golden triangle
just wondering if anyone is having similiar results
mac client is running 10.5.8

The path to your home folder is too long I think. This script is trying to pull the middle value of a traditional \\server\share\folder format. You have an IP\server\share\folder format.

The only workaround you may want to try is sharing the "class02" folder on the server and in Active Directory map a user's home folder to \\serverIP\class02\username

This should pull the value of class02 and attempt to open the correct home folder.

im after changing the location of the share from class02 to the root of the share (mactest)
so, in AD the users home folder is set as \\192.168.10.44\mactest\xfinemedia

its still doing the same thing, so i created a new user and called it "finemedia", logged on and checked the console for the output from the script:

22/04/2010 13:59:32 login.plist[3012] finemedia
22/04/2010 13:59:32 login.plist[3012] SMBHome: \192.168.10.44\mactestinemedia

just noticed aswell, if i look at the console, it says
SMBHome: \192.168.10.44\mactest
but if i drag the line entry in the console to this text box it displays differently
22/04/2010 13:59:32 login.plist[3012] dsAttrTypeNative:homeDirectory: \147.252.26.139\mactestinemedia

im at a loss with this one.
the funny thing is i created a user called "media_test10" and their home folder is in
\\192.168.10.44\mactest\class02\media_test10 and when i logon as them, it outputs it ok to the console, so dont think its a problem with the amount of characters in the home folder.

Whenever you see the dsAttr string, it means directory services attribute. Since directory services is the service used to relay user info from the berkley database on both the local client and OS X Server. It stores information like, default shell, location of home folder, user name, password, users/groups, and so forth.

So what you are seeing is the 'under-the-hood,' technology that the GUI masks from the end user.

sorry, i just made things more confusing there by adding in that line that contains the dsAttr string.
I had an extra line to return the SMBHome and the homeDirectory just to see if the results were different

#!/bin/sh
sleep 5
ls -l /dev/console | awk '{print $3}'
USER=$(ls -l /dev/console | awk '{print $3}')
echo $USER
SMB=`(dscl /Active\ Directory/All\ Domains -read /Users/$USER homeDirectory)`
SMB2=`(dscl /Active\ Directory/All\ Domains -read /Users/$USER SMBHome)`
echo $SMB
echo $SMB2

You mentioned that the dsAttr was relaying information from the directory. The problem is that if i open up a terminal window and used the dscl command and queried /Active Directory/All Domains/Users/finemedia and done a read command on this to display all of the directroy information, one of the entries there is SMBHome, which contains the value:
SMBHome: \192.168.10.44\mactest\finemedia
this is fine, thats what i want to see
but, the script i have running above (which is being called by a launch agent) doesnt return the value that its supposed to.

On some occassions, it returns the value
SMBHome: \192.168.10.44\mactest\
(i.e. it will be missing abit at the end)
and on other occassions it will return:
SMBHome: \192.168.10.44\mactestinemedia
(i.e. it looks as if it the last two fields of the address have been mashed together)

The bizzare thing is that i have tested this out on a load of different test users, and any test users that start with "media" (e.g. media_test10, media_test11, etc) all return the correct value, whereas if they start with the word "fineart" or "xfine.." then it seems to return only part of the value of SMBHome or else a "mashed up" version

What about using quotes?
I.e.,
echo "$SMB"
instead of
echo $SMB

If I recall, wasn't someone using a wild card in the script at some point? I scrolled back but could not find it (due to being too busy at work), but I swear someone was using a wild card for file paths.

If this is the case, try getting rid of the wild card.

not using wildcards at all.
the script is only a few lines long (below), and all it is doing, is getting the currently logged on user, storing this as a variable called "USER", and then running a dscl query using that variable to get the value for SMBHome.

#!/bin/sh
sleep 5
ls -l /dev/console | awk '{print $3}'
USER=$(ls -l /dev/console | awk '{print $3}')
echo $USER
SMB=`(dscl /Active\ Directory/All\ Domains -read /Users/$USER SMBHome)`
echo "$SMB"

I have tried putting Quotes around $SMB but it still outputs it all mashed up.
just to eliminate a few things, i have created 2 new users.
One is called media_test100
the other is called fedia_test100
both have home folders located on \\192.168.10.44\mactest\class02\<username>

when logging on as media_test100, the script runs and outputs to the console:
23/04/2010 08:59:32 login.plist[3012] SMBHome: \192.168.10.44\mactest\class02\media_test100
This is correct.

when i log on as the user fedia_test100, the script runs and outputs to the console:
23/04/2010 09:02:02 login.plist[3017] SMBHome: \192.168.10.44\mactest\class02

But, ive just modified the script to output the results to a text file aswell as the console and the results are different. The text file seems to display it ok whereas the console doesnt.
strange one, so may have to go back to the idea of outputing the result to txt, then reading it back into the script

Do the short names match? The command that pulls the user name from the console, will be the user's short name.

Just another stumbling block we have hit with integrating our macs into AD.
We have our login script running without any problems.
It basically redirects the users documents folder to the home folder on a windows server.

Client is 10.5 (also 10.6), connected to a win2k3 AD domain, and a 10.6 mac server (golden triangle)

We have come across a problem in that, if you add a shortcut to a windows share onto the dock of the client (via workgroup manager) the user is prompted for a username and password, even though the user gets a kerberos ticket when they login using their AD credentials

I have looked around the net on this, and some people are saying this is a problem with 10.5 and 10.6
Anyone got any ideas?