Skip to main content

We have a couple of different default user accounts, created with CreateUserPKG, that we might deploy on a machine at imaging time as generic local user accounts (not all users might be employees so we need some local machine accounts).



So, one user we deploy might have UID 503. When we image the machine some preference files are copied to all users home (per the option for that deployment dmg file), but the preference files don't inherit the UID of the folder's user (503), instead sticking to the UID of the account on the machine the preferences were made on (501 for example). Since the local user doesn't share that UID it can't read the file and ignores it for a new default preference file.



Am I missing something? Or should I just look at a script to chown files at the end of imaging?

Using the FEU flag? I assume the priorities of the CreateUserPkg-created account creation packages are a lower number/higher priority than those that FUT.



So the files are getting there, but aren't owned by the user? That seems like a bug...


Its always worked for me, although over the past year or so I've been using it less and less.



Does sound like a bug. It's not 9.72 is it?



Probably best to add a chown -R at the end just to be safe.


Yeah, the CreateUserPkg accounts are being created at priority 9 just to make sure most everything runs after them.



I'm still running 9.65.



I've got the following script cribbed and pared down from someone else to run (with -R grin). It seems to be fixing the permissions problems I was seeing with some other preferences as well.



#!/bin/bash
localUsers=$( dscl . list /Users UniqueID | awk '$2 >= 501 {print $1}' | grep -v admin )

for userName in "$localUsers"; do
chown -R $userName /Users/$userName/Library/
done


Not really 'solved' but it does the trick.



It'd be nice if CreateUserPkg had a feature where you could choose to let the pkg use the next available UID in some cases if the default is already used.