From: Marco Recuay <marco@(email surpressed)>
Subject: After Effects Write Permissions Errors
   Date: Thu, 24 Jan 2008 23:09:08 -0500

This is on OS X 10.4.10, with NFS file shares.

Any ideas?

Marco Recuay wrote:
> [posted to rush.general]
> 
> Has anyone else encountered strange write permissions errors when 
> rendering After Effects in OS X?
> 
> aerender Error: After Effects error: Error in output for render queue 
> item 1, output module 1. Can not create a file in directory 
> /private/var/automount/blah/blah. Try checking write permissions.
> 
> This error occurs on 3-5% of frames, and re-queuing works fine. This 
> has occured on all AE versions from 6.5 to 8.0. There are no write 
> permissions problems upon inspection, so I dont know how to solve it.
> 
> This is on OS X 10.4.10, with NFS file shares.
> 
> Any ideas?

	Does the problem always seem to happen on a particular machine?
	Possibly one or two machines don't have the file server mounted
	properly.

	To troubleshoot, try to replicate the problem from the
	command line:

I) Look at one of the frames that fails with the error,
   and make note of:
	
        1) the machine it failed on
        2) the 'RunningAs:' line in the frame log

II) Login to that machine using either ssh or telnet, logging in
    as the same user shown the render was running as (ie. the 'RunningAs:'
    line from the frame log)

III) From the unix prompt, try to access the directory in question, eg:

	ls -la /private/var/automount/blah/blah
	echo hello > /private/var/automount/blah/blah.txt

If you're able to replicate the error, then trouble shoot it that way.
Could be the mount to your file server is not mounted on that machine.

* * *

	I should point out the path /private/var/automount/blah/blah
	looks wrong.. that should probably be more like /Volumes/blah/blah

	Me, I don't trust the automounter, and prefer to making static
	mounts by hacking mount commands into the boot scripts, such as
	is described in steps #3 and #4 of this article:

http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1295+1295+1297+1298

	Usually it just comes down to a simple command like:

mount -t nfs server:/somedir /jobs/somedir

	..where /jobs/somedir is an empty directory that you mount your
	file server onto via NFS.

	Regardless of if it's a mount problem, or user access problem,
	you should be able to replicate the problem from the unix prompt,
	assuming you ssh or telnet over to the machine in question and
	login as the same user the render was trying to run as.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Would this be the correct way to add this error handling?

# HANDLE EXIT CODES
	if ( $exitcode == 0 )			# OK?
	    { print STDERR "\n--- AERENDER SUCCEEDS\n"; exit(0); }
	elsif ( $exitcode == 9 )	# WEIRD WRITE PERMISSION ERROR

	elsif ( $exitcode > 0 && $exitcode < 128 )	# NON-ZERO EXIT
	    { print STDERR "--- AERENDER FAILED: EXITCODE=$exitcode\n"; exit(1); }
	elsif ( $exitcode )				# SEGFAULT/SIGNAL
	    { print STDERR "--- AERENDER FAILED: $errmsg\n"; exit(1); }

I think this should work, but I am no good with perl.

Marco

On 2008-01-24 22:49:27 -0800, Greg Ercolano <erco@(email surpressed)> said:

	Does the problem always seem to happen on a particular machine?
	Possibly one or two machines don't have the file server mounted
	properly.

	To troubleshoot, try to replicate the problem from the
	command line:

I) Look at one of the frames that fails with the error,
   and make note of:
	
        1) the machine it failed on
        2) the 'RunningAs:' line in the frame log

II) Login to that machine using either ssh or telnet, logging in
    as the same user shown the render was running as (ie. the 'RunningAs:'
    line from the frame log)

III) From the unix prompt, try to access the directory in question, eg:

	ls -la /private/var/automount/blah/blah
	echo hello > /private/var/automount/blah/blah.txt

If you're able to replicate the error, then trouble shoot it that way.
Could be the mount to your file server is not mounted on that machine.

* * *

	I should point out the path /private/var/automount/blah/blah
	looks wrong.. that should probably be more like /Volumes/blah/blah

	Me, I don't trust the automounter, and prefer to making static
	mounts by hacking mount commands into the boot scripts, such as
	is described in steps #3 and #4 of this article:

http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1295+1295+1297+1298

	Usually it just comes down to a simple command like:

mount -t nfs server:/somedir /jobs/somedir

	..where /jobs/somedir is an empty directory that you mount your
	file server onto via NFS.

	Regardless of if it's a mount problem, or user access problem,
	you should be able to replicate the problem from the unix prompt,
	assuming you ssh or telnet over to the machine in question and
	login as the same user the render was trying to run as.

# HANDLE EXIT CODES
if ( $exitcode == 0 )			# OK?
   { print STDERR "\n--- AERENDER SUCCEEDS\n"; exit(0); }
elsif ( $exitcode == 9 )	# WEIRD WRITE ERROR
   { print STDERR "--- AERENDER FAILED...REQUEING: EXITCODE=$exitcode\n"; }
elsif ( $exitcode > 0 && $exitcode < 128 )	# NON-ZERO EXIT
   { print STDERR "--- AERENDER FAILED: EXITCODE=$exitcode\n"; exit(1); }
elsif ( $exitcode )				# SEGFAULT/SIGNAL
   { print STDERR "--- AERENDER FAILED: $errmsg\n"; exit(1); }

-Marco


On 2008-01-28 19:18:38 -0800, Marco Recuay <marco@(email surpressed)> said:

The error can occur on any machine, so the problem is universal, and the fact that it seems to occur randomly makes it really hard to troubleshoot. I was hoping someone else had seen the problem, but its not a show stopper.

I'm going to go ahead and try editing the submit-afterfx.pl and see if I can just tell it to requeue if it happens, as requeuing will fix the problem.

Would this be the correct way to add this error handling?

# HANDLE EXIT CODES
	if ( $exitcode == 0 )			# OK?
	    { print STDERR "\n--- AERENDER SUCCEEDS\n"; exit(0); }
	elsif ( $exitcode == 9 )	# WEIRD WRITE PERMISSION ERROR

{ print STDERR "--- AERENDER FAILED...REQUEING: EXITCODE=$exitcode\n"; exit(2); }

	elsif ( $exitcode > 0 && $exitcode < 128 )	# NON-ZERO EXIT
	    { print STDERR "--- AERENDER FAILED: EXITCODE=$exitcode\n"; exit(1); }
	elsif ( $exitcode )				# SEGFAULT/SIGNAL
	    { print STDERR "--- AERENDER FAILED: $errmsg\n"; exit(1); }

I think this should work, but I am no good with perl.

As for the weird automounter issues with /private/var/automount/... I did a test install of Leopard, and it appears they have fixed automounts so they mount only at the point specified in LDAP, so thats good news.

On a side note, I tried the old AFP doesnt support multiple users bug out in Leopard, and its still broken. Login as User A, with write priveleges to AFP server 1. Then from the unix prompt, login as User B with write priveleges to server 1. Yet User B has no priveleges. Booo.

Marco

Marco Recuay wrote:
> Just for completeness, the adjustment to afterfx-submit.pl that added 
> requeing for this error specifically:
> 
> # HANDLE EXIT CODES
> if ( $exitcode == 0 )			# OK?
>     { print STDERR "\n--- AERENDER SUCCEEDS\n"; exit(0); }
> elsif ( $exitcode == 9 )	# WEIRD WRITE ERROR
>     { print STDERR "--- AERENDER FAILED...REQUEING: EXITCODE=$exitcode\n"; }
> elsif ( $exitcode > 0 && $exitcode < 128 )	# NON-ZERO EXIT
>     { print STDERR "--- AERENDER FAILED: EXITCODE=$exitcode\n"; exit(1); }
> elsif ( $exitcode )				# SEGFAULT/SIGNAL
>     { print STDERR "--- AERENDER FAILED: $errmsg\n"; exit(1); }

> Just needed to remove the exit() code from the end of the line, and it 
> now runs through the retry count after failing.

	Yes, sounds right.

	By removing the exit(2); you had previously, it won't requeue
	to some other machine, but rather will fall through to the
	retry loop (just as you said), so that it tries on this same machine
	up to the number of retries configured for the Retries: prompt
	in the submit form.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)