Well after a rebuild I've discovered the rather bizarre apparent cause of the problem; when you run a Maya desktop session under Linux an additional set of .mel preferences files are created under ~/maya/2011-x64/prefs which do not exist on the mac. Even though they all seem to relate solely to GUI session configuration, the Render command will not execute properly without them, at least in the case of the scene we encountered.
On a somewhat related note does anyone have a good guide for configuring rayrc files? I'm trying to resolve whether or not particular render issues relating to MentalRay Standalone are caused by improper formatting of my centralized rayrc and maya.rayrc files. I also cannot confirm settings and environment variables by placing echo statements into the rayrc's; they all echo the variable name (i.e. "{_MI_REG_INCLUDE}") but not the value. Preceding it with a $lookup call also has no effect. The existing documentation is of little help to me and seems to mostly gloss over the whole area.
On Feb 22, 2011, at 7:55 AM, Greg Ercolano wrote:
[posted to rush.general]
Others feel free to chime in..
First and foremost, these errors are an indication something
is very wrong, regardless of maya or scene files.
> rushd: WARNING: chdir(/var/tmp/.RUSH_TMP.190): Permission denied
> [..]
> Error: default temp directory /usr/tmp does not have write permissions.
> *** Fatal Error: Failed creating directory: /usr/tmp
Correct those, and the maya scene file issues will likely
go away as well.
Some are messages from rush, some are from maya. Both indicate
perm problems with /var/tmp. (often /usr/tmp and /var/tmp are
the same dir; the former being a link to the latter)
There are at least two things that have been added to linux
(and OSX) over the years that affect the way permissions
are handled: acl's and selinux (see 'man acl' and 'man selinux')
So you'll want to check those.
Also, traditional unix perms can create this situation as well
(eg. someone enabling an improper sticky bit on eg. the /var/tmp dir)
You mentioned you disabled selinux; though I don't right away
suspect that given the above, what technique did you use?
Did you disable it in grub, or /etc/sysconfig/selinux, or both?
Try checking your work to make sure it's off:
selinuxenabled; echo $?
From the selinuxenabled(8) man page:
>> It exits with status 0 if SELinux is enabled and 1 if it is not enabled
|