are you connected as root ?  Doesn't sound like it.  The script 
runs under the context of the connected user.

No, I'm not connected as root, but the documentation explicitly says that the
script will run as root. Note that this is required because the functionality
of the script depends on that. Usually the "add script user" script will
change /etc/passwd to add the user, etc, and it must be done from an non-root 
user connection but with the script running as root. 

The add user script is used for 2 things.  

(a) The samr_create_user call which is done under the 
    context of the connected user, and 
(b) one behalf of a user when security = domain and 
    you are not running winbindd.

which case are you talking about ?

The (a) option can't be possible because the user doesn't exist in the 
system yet (because that, the "add user script" must be runned).

I don't really understand you about (b), but i'm using security=user, so
probably is not my case, but note that the user also doesn't exist yet.

From the smb.conf manpage under the "add user script" section:
 "This is the full pathname to a script that will be run AS ROOT by smbd(8) 
under special circumstances described below."
 (...)
 "This option allows smbd to create the required UNIX users ON DEMAND when a 
  user accesses the Samba server."

Note, I found this bug using Samba 3.0.2rc2, I didn't checked again with
3.0.2, and now I'm using winbind, so this bug doesn't affect me anymore.

I've had the same problem on both 3.0.0 and 3.0.2

When creating a user calling the add user script via smb.conf from User 
Manager, I get an access denied error.

Other scripts called from smb.conf seem to be working OK.

The log file shows the user being created and then immediately deleted, but no 
changes to the passwd files, altough the same command string works fine from 
the console.

It appears to a problem unlocking and writing to the passwd files, which would 
happen if the script is executed from a non-root account.

I am connecting as root, which indicates to me the context of the connected 
user is not the issue here, but who the script gets called as from the smbd.

closing out.  If there is a problem specifically 
with user manager support, plezse open a different bug.  Thanks.

database cleanup