Got it figured out; apparently InstaDMG REALLY doesn’t like it when you have an empty folder in your workflow! Removing it allowed the build to complete without any issues. You live, you learn!
Got it figured out. Turns out that the issue was with the “T” flag. I removed it from my instadmg command, and the 10.7.4 InstallESD was able to mount. Hope this helps someone.
FYI, I was able to copy all of the PKG files from the install DVD and use the “Packages” app to roll them into an MPKG (in the order posted by purpanther). Iceberg and Packagemaker will not work, since these are flat packages.
One request for the author of the “PatchOfficeUpdate” script/droplet (mosen?); could you please update your script for Office 2011? I would like to include the 14.0.1 update in my build train, but it fails to install. Incidentally, I edited the existing patcher with the path to my Office 2011 installation as follows, but it did not allow the update to be installed in InstaDMG:
# Remove the volume check from the distribution script.
sed ‘/function volumeOs1049OrHigher/a \
return true;
‘ “$DISTRIBUTION_FILE” > “$DISTRIBUTION_FILE.tmp”
[QUOTE][u]Quote by: superrcat[/u]
By selecting ‘Create mobile account at login’, ‘Force local home directory on startup disk’, and ‘Use UNC path from Active Directory to derive network home location’ you will provide network users with cached credentials for offline client access, a home directory stored locally on the client and their network file space mounted at login (when connected to the network).[/QUOTE]
In my setup, when I follow this arrangement and choose “Use UNC Path…”, my home directory is placed on the network, and the credentials are not cached in Netinfo. Un-checking it causes the credentials to be cached, but they do not get their network drive mounted.
I am using AD for auth and a Windows server running ExtremeZ-IP for users’ network drives.
FYI… Still trying to get cached credentials working for our laptop users, who we currently set up with local accounts.
I can attest to having this issue as well, however I see it only when the “create mobile account at login” checkbox is selected. I see the same errors in the log that you are describing:
Aug 1 09:45:17 A200428 automount[186]: Can't mount ben.butler.edu:/acunning on /private/Network/Servers/ben.butler.edu/acunning: Permission denied (13)
Aug 1 09:45:21 A200428 automount[440]: Can't mount ben.butler.edu:/acunning on /private/Network/Servers/ben.butler.edu/acunning: Permission denied (13)
Aug 1 09:45:21 A200428 automount[440]: Attempt to mount /automount/Servers/ben.butler.edu/acunning returned 13 (Permission denied)
Aug 1 09:45:21 A200428 automount[186]: Can't mount ben.butler.edu:/acunning on /private/Network/Servers/ben.butler.edu/acunning: Permission denied (13)
Aug 1 09:45:25 A200428 automount[443]: Can't mount ben.butler.edu:/acunning on /private/Network/Servers/ben.butler.edu/acunning: Permission denied (13)
Aug 1 09:45:25 A200428 automount[443]: Attempt to mount /automount/Servers/ben.butler.edu/acunning returned 13 (Permission denied)
Aug 1 09:45:25 A200428 automount[186]: Can't mount ben.butler.edu:/acunning on /private/Network/Servers/ben.butler.edu/acunning: Permission denied (13)
Aug 1 09:45:29 A200428 automount[446]: Can't mount ben.butler.edu:/acunning on /private/Network/Servers/ben.butler.edu/acunning: Permission denied (13)
Aug 1 09:45:29 A200428 automount[446]: Attempt to mount /automount/Servers/ben.butler.edu/acunning returned 13 (Permission denied)
Aug 1 09:45:29 A200428 automount[186]: Can't mount ben.butler.edu:/acunning on /private/Network/Servers/ben.butler.edu/acunning: Permission denied (13)
I found this post on Apple’s boards, which sheds a bit of light on things:
Looks like a major bug with Apple’s authentication setup!
I’m going to try to change some auth settings on my clients to see if this helps, and also work with our Windows admin to see what is happening on the server side.
I can also attest to some oddness, although it’s probably my fault. Recently I have been unable to login to machines (iBooks) that are bound to active directory if the “create mobile account at login” checkbox is ticked. Deselecting this option allows logins to continue. The logs show an inability to mount the user’s share (UNC path) at /private/Network/Servers/servername/username/ with permissions errors. These errors continue indefinitely. The result is that the login panel hangs with a spinning pinwheel of doom.
I later discovered that there was an issue with the image that I was using on the machines displaying this odd behavior. I had made the mistake of creating my image from a machine that was already bound to active directory. I am not sure whether this is the cause of this login oddness or not (manually removing the machine record from AD didn’t seem to change matters). I’m currently rebuilding my image from scratch, and I’ll report results.
I finally have managed to get this working. The only caveat is that in order for the Authentication and Search paths to be properly set, the paths for both must be set to “Automatic” in Directory Access prior to running the script. I also omitted the sections where host/computer names are set, as NetRestore does this for me already.
OK, I just wiped out the entire “Mounts” entry in my directory access config. Here’s what was there. The entries on the right are what I had these attributes mapped to.
I did an “allMounts” using lookupd in debug mode, and I found this:
==> 1 object
[
Dictionary: "D-0x003042f0"
_lookup_agent: DSAgent
_lookup_validation: 1099366638
dir: /Network/Servers/
name: xserve:/Volumes/Server HD/Users
vfstype: url
+ Category: mount
+ Time to live: 0
+ Age: 0 (expires in 0 seconds)
+ Negative: No
+ Cache hits: 0
+ Retain count: 2
]
<== 1 object
Obviously, this is bad. My predecessor was working on automounts, apparently, and I somehow managed to roll out a directory access config that contained his deprecated setup! Ugh!
How would I go about getting rid of this?! Which attributes in LDAP might hand out this info? Please help!
After further testing, the script, although unnecessarily complex, works fine. The problem was with the com.apple.loginwindow.plist file. For some reason it had become corrupted, and the LogoutScript portion was missing!
Any idea as to why this preference file gets borked occasionally? I’m beginning to think that I should be using Radmind or something similar to ensure that these crucial files do not get screwed up…
For those who are interested, here’s how I simplified my script:
#!/bin/bash
uid="$USER"
home="/Users/$uid"
time=`date ''+%m-%d-%y_%H.%M.%S''`
if [ "$uid" != "infores" ]; then
rm -f /Library/Classic/Classic.dmg.shadow
mkdir -m 755 "/private/tmp/$uid.$time"
mv $home "/private/tmp/$uid.$time"
fi
exit 0
Recent Comments