Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

at command returns 0481-166

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
As user root there's no problem, but as another user the 'at'-command returns "0481-166 The auditproc function failed with errno 1".
This specific user has the Audit class general and this problem does not occur on another RS/6000 with the same AIX version.
What could be the problem?
 
Possibly?

The /var/adm/cron/at.allow and /var/adm/cron/at.deny files control which users can use the at command. A person with root user authority can create, edit, or delete these files. Entries in these files are user login names with one name to a line. The following is an example of an at.allow file:

If the at.allow file exists, only users whose login names appear in it can use the at command. A system administrator can explicitly stop a user from using the at command by listing the user's login name in the at.deny file. If only the at.deny file exists, any user whose name does not appear in the file can use the at command.

A user cannot use the at command if one of the following is true:

The at.allow file and the at.deny file do not exist (allows root user only).
The at.allow file exists but the user's login name is not listed in it.
The at.deny file exists and the user's login name is listed in it.
If the at.allow file does not exist and the at.deny file does not exist or is empty, only someone with root user authority can submit a job with the at command.

 
From the 'at' man pages:

A user cannot use the at command if one of the following is true:

o The at.allow file and the at.deny file do not exist (allows root user only).
o The at.allow file exists but the user's login name is not listed in it.
o The at.deny file exists and the user's login name is listed in it.

If the at.allow file does not exist and the at.deny file does not exist or is empty, only someone with root user authority can submit a job with the at command.

 
I knew this.
But at.deny existed (empty). Just in case, I created at.allow with several users, but the error still returns.

 
Do you have some different user authentication or password verification set for the users? Just a guess. Check the user settings on both systems, see if something is different. If files are referenced (for passwd verif, for example) make sure they exist on the machine. IBM Certified -- AIX 4.3 Administration
IBM Certified -- AIX 4.3 Support
IBM Certifiable!
 
We experienced a similar problem when upgrading to 4.3 a while back. I had to go in and set the user's daemon flag to 'true'.

chuser daemon=true userid

HTH
 
The solution:
File attributes of /usr/bin/at was: -rwxrwxrwx (did the installer this?)
With chmod 6555 /usr/bin/at the problem was solved!

pffff ... costed a few days and its that simple :(
 
The solution:
File attributes of /usr/bin/at was: -rwxrwxrwx (did the installer this?)
With chmod 6555 /usr/bin/at the problem was solved!

pffff ... costed a few days and its that simple :(
 
Yeah, they are all simple after you fix them =).

Might want to check over root's umask. The guy next to me had something other than normal when he updated bos.rte.security and no one could log in except for root at the console. IBM Certified -- AIX 4.3 Obfuscation
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top