> I have a Mac network that uses:
>
> - Domain logins every where
> - No chnages to rush.conf
> - Home dirs local only with no roaming profiles
>
> Every time I ran Rush, the process would run as the user submitting
the job.
> However this error would occur in /var/log/system.log;
>
> "aerender: kCGErrorRangeCheck : Window Server communication from
outsode of session allowed for root and console user only"
Yes, this is essentially the same error as the one described here
on the "After Effects Issues" page:
http://www.seriss.com/rush-current/ae6/index.html#OSX
..you might want to check that whole page for other AE related stuff.
After Effects is unusual in that its network renderer still invokes
the GUI, which means it must have permission to access the machine's
window manager.
The Adobe engineers have configured After Effects in 6.5 so that
it opens the GUI in such a way that it isn't seen by the user of
the window manager, but AE still needs permission to the window
mananger to run correctly.
This means using the setuid tweak on the aerender executable
to make things work.
> So I chose to chmod u+s aerender and chown it to root as well.
Yes, should solve the problem.
> I then got this error in rush logs for that particular frame;
>
> "After Effects error: finding preferences folder N no such volume (-35)"
> "aerender ERROR -600: GetProcessForPID failed at line 847"
>
> So I created a home dir local on that render node that was the same
as the user submitting the job.
Not sure how you created the user's account without their home
directory being created, but yes, the user the render runs as
needs to have a home directory.
Most programs (AE, Maya, etc) assume the user has a home directory
so that it can load/save preference files, create tmp files, etc.
Without that, the apps won't run, and often give obscure error
messages like the above. (Maya does this too)
To allow users to render on the nodes, the nodes must have valid
accounts on each node (ie. same account names with same uid/gid values,
and home dirs chowned/chmoded correctly).
The only exception would be if you're using 'forceuid/forcegid' to
force all renders to run under a single user account, in which case
you only need to make sure /that/ account exists on all the nodes.
The forceuid/gid stuff is useful if you want to just have
everything render under a single user account, so you don't
have to add new user accounts to all the machines.
> I guess there is no real elegant way around the OSX window issue and
> is something I should be well versed in for doing correct installs.
Yes; Apple provides no permission mechanism workaround
for this problem.
The ball is really in Adobe's court; they need to make the command
line renderer avoid doing anything to the Window Manager, so that
it is more like other command line apps (maya, shake, etc).
Adobe's engineers are aware of the problem, and working on it.