Informix does not have permission to define replicate: Error 61
On Informix 9.40.UC1 (AIX), the informix user suddenly couldn't run most cdr commands, getting error 61 ("user doesn't have permission to issue command"). Suggestions included checking cdr binary permissions and the 9.40 release-note requirement that $INFORMIXDIR, ONCONFIG and sqlhosts permissions/ownership be unchanged, plus checking informix's OS group-id — none applied. The poster then found related symptoms (objects created while su'd to informix were owned by the original user, error 635/313 on drops). The cause turned out to be a $HOME/.netrc file for informix containing non-informix user entries; replacing them with informix's own credentials fixed it, though no one explained why .netrc was consulted.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
We have a few database instances all are running Informix 9.4 on AIX P660. We created and tested database replication on two of the servers, which have been running successfully for over a month. Today, we promoted and define replication on our production system, and of course, things began to ski downhill... Informix user does not have permission to run cdr command (except for cdr list...). Here is the error I got: ------------------- command failed -- user doesn't have permission to issue command (61) ------------------- All the usual environment variables are defined correctly. INFORMIXDIR, INFORMIXSERVER, ONCONFIG, etc, etc. We have never encountered this during the beta test. And both the test and production systems are running the same OS and informix version. Any idea what could have caused this? Thanks, BAFFLED!
Chariya Peterson wrote: > > We have a few database instances all are running Informix 9.4 on AIX > P660. > We created and tested database replication on two of the servers, which > have been running successfully for over a month. Today, we promoted > and define replication on our production system, and of course, things > began to ski downhill... > > Informix user does not have permission to run cdr command (except for > cdr list...). Here is the error I got: > > ------------------- > command failed -- user doesn't have permission to issue command (61) > ------------------- > > All the usual environment variables are defined correctly. > INFORMIXDIR, INFORMIXSERVER, ONCONFIG, etc, etc. > > We have never encountered this during the beta test. And both the test > and production systems are running the same OS and informix version. > Any idea what could have caused this? > > Thanks, > > BAFFLED! 9.40.??? ls -l $INFORMIXDIR/bin/cdr should be : -rwxr-xr-x 1 informix informix 1997976 Jan 23 07:31 /usr/informix/9.40.FC2/bin/cdr
"Chariya Peterson" <Chariya.Peterson@noaa.gov> wrote in message news:40686972.4FD0DD98@noaa.gov... > > > We have a few database instances all are running Informix 9.4 on AIX > P660. 9.40.UC3?? Read the release notes about permissions on things. The latest UC3 is much stricter on permissions... > We created and tested database replication on two of the servers, which > have been running successfully for over a month. Today, we promoted > and define replication on our production system, and of course, things > began to ski downhill... > > Informix user does not have permission to run cdr command (except for > cdr list...). Here is the error I got: > > ------------------- > command failed -- user doesn't have permission to issue command (61) > ------------------- > > All the usual environment variables are defined correctly. > INFORMIXDIR, INFORMIXSERVER, ONCONFIG, etc, etc. > > We have never encountered this during the beta test. And both the test > and production systems are running the same OS and informix version. > Any idea what could have caused this? > > Thanks, > > BAFFLED!
"Chariya Peterson" <Chariya.Peterson@noaa.gov> wrote in message news:40686972.4FD0DD98@noaa.gov... > > > We have a few database instances all are running Informix 9.4 on AIX > P660. > We created and tested database replication on two of the servers, which > have been running successfully for over a month. Today, we promoted > and define replication on our production system, and of course, things > began to ski downhill... > Found it ...http://publibfi.boulder.ibm.com/epubs/html/25119530.html A. Database Server Usability Enhancements 1. Server Utilities Check for Secure Environment Before Starting To provide increased security, key server utilities now check to determine if your environment is secure. Before the server will start, the following settings must be unchanged from the settings established during installation: - The permissions on $INFORMIXDIR and some directories under it.For each directory, check that the directory exists, that it is owned by user informix and the correct group (listed below), and that its permissions do not include write permissions for the group or other users. - The permissions on the ONCONFIG file - The permissions on the sqlhosts file - Filename lengths. The length of both the filenames $INFORMIXDIR/etc/onconfig.std and $INFORMIXDIR/etc/$ONCONFIG must be less than 256 characters. > Informix user does not have permission to run cdr command (except for > cdr list...). Here is the error I got: > > ------------------- > command failed -- user doesn't have permission to issue command (61) > ------------------- > > All the usual environment variables are defined correctly. > INFORMIXDIR, INFORMIXSERVER, ONCONFIG, etc, etc. > > We have never encountered this during the beta test. And both the test > and production systems are running the same OS and informix version. > Any idea what could have caused this? > > Thanks, > > BAFFLED!
TBP wrote: > > Chariya Peterson wrote: > > > > 9.40.??? It is 9.40.UC1 > > ls -l $INFORMIXDIR/bin/cdr > > should be : > > -rwxr-xr-x 1 informix informix 1997976 Jan 23 07:31 > /usr/informix/9.40.FC2/bin/cdr Mine is -rwxr-xr-x 1 informix informix 1756851 Feb 05 2003 ../bin/cdr*
David Williams wrote: > > "Chariya Peterson" <Chariya.Peterson@noaa.gov> wrote in message > news:40686972.4FD0DD98@noaa.gov... > > > > Found it ...http://publibfi.boulder.ibm.com/epubs/html/25119530.html > > A. Database Server Usability Enhancements > > 1. Server Utilities Check for Secure Environment Before Starting > > To provide increased security, key server utilities now check to determine > if your environment is secure. Before the server will start, the following > settings must be unchanged from the settings established during > installation: > > - The permissions on $INFORMIXDIR and some directories under it.For each > directory, > check that the directory exists, that it is owned by user informix and the > correct group (listed below), and that its permissions do not include > write > permissions for the group or other users. > - The permissions on the ONCONFIG file > - The permissions on the sqlhosts file > - Filename lengths. The length of both the filenames > $INFORMIXDIR/etc/onconfig.std and $INFORMIXDIR/etc/$ONCONFIG > must be less than 256 characters. The Informix version 9.40.UC1 I checked and double checked. None of the file/directory permission has changed. No long file name. Still baffled chariya peterson
Chariya Peterson wrote: > > We have a few database instances all are running Informix 9.4 on AIX > P660. > We created and tested database replication on two of the servers, which > have been running successfully for over a month. Today, we promoted > and define replication on our production system, and of course, things > began to ski downhill... This error may be related to non-cdr error I had earlier today: First. When informix tried to drop a trigger on a table owned by informix, I got error 635 (Not owner of object). However, if I start dbacces and logon to informix, then I can drop the trigger succesfully. Note: The whoami command showed "informix". The status of the table showed that it is owned by "informix". I tried all three possibilities: su - informix, su informix, or logon to the system as informix and drop thr trigger withutany success. Chariya
Chariya Peterson wrote:
>
> We have a few database instances all are running Informix 9.4 on AIX
> P660.
After poking around the system, I found the following:
1. When I became informix (whether it is throguh su, su -, ssh or
telnet) and create a table of any database object, Informix still list
the original user (me) as the owner of the object instead of
"informix".
2. As informix, I opened a dbacces session and tried to drop a table
(owned by informix) I got 313 error (not owner). But I am able to drop
the table if I connect to the database (from inside dbaccess) as
informix.
3. For completeness sake, which I bet most of you would have already
guess the result.... If I connect within dbaccess as informix and
create a table. Exit dbaccess and, as informix, open another dbaccess
session. I cannot drop the table.
Anyone recongnizes this symptom and able to shred some light one me ?
Thnaks,
chariya peterson
Chariya Peterson <Chariya.Peterson@noaa.gov> wrote in message news:<4068876E.5B05B571@noaa.gov>... > Chariya Peterson wrote: > > > > We have a few database instances all are running Informix 9.4 on AIX > > P660. > > We created and tested database replication on two of the servers, which > > have been running successfully for over a month. Today, we promoted > > and define replication on our production system, and of course, things > > began to ski downhill... > > > This error may be related to non-cdr error I had earlier today: > > First. When informix tried to drop a trigger on a table owned by > informix, > I got error 635 (Not owner of object). However, if I start dbacces and > logon to informix, then I can drop the trigger succesfully. > > Note: The whoami command showed "informix". > The status of the table showed that it is owned by "informix". You might want to check to see if the group-id of informix has been recently changed in the OS. Check out "ls -ld $INFORMIXDIR/etc" M.P. > > I tried all three possibilities: > su - informix, > su informix, or > logon to the system as informix > and drop thr trigger withutany success. > > > Chariya > --
mpruet wrote: > Chariya Peterson <Chariya.Peterson@noaa.gov> wrote in message > news:<4068876E.5B05B571@noaa.gov>... >> Chariya Peterson wrote: >>> >> This error may be related to non-cdr error I had earlier today: >> >> First. When informix tried to drop a trigger on a table owned by >> informix, >> I got error 635 (Not owner of object). However, if I start dbacces >> and logon to informix, then I can drop the trigger succesfully. >> >> Note: The whoami command showed "informix". >> The status of the table showed that it is owned by "informix". > > You might want to check to see if the group-id of informix has been > recently changed in the OS. Check out "ls -ld $INFORMIXDIR/etc" > > M.P. >> THe permission is 755, owner informix, group informix. cpeterso@saaprod2 $ ls -ld $INFORMIXDIR/etc drwxr-xr-x 3 informix informix 2048 Mar 29 15:30 /usr/informix/etc/ cpeterso@saaprod2 $
Chariya Peterson <Chariya.Peterson@noaa.gov> writes: Mark Oberfield wrote: > Chariya Peterson wrote: >> >> We have a few database instances all are running Informix 9.4 on AIX >> P660. > > After poking around the system, I found the following: > > 1. When I became informix (whether it is throguh su, su -, ssh or > telnet) and create a table of any database object, Informix still list > the original user (me) as the owner of the object instead of > "informix". Odd. We had something like this occur with a 7.31 system. As it turned out, a field office had a $HOME/.netrc file which allowed the user to log in as informix on the server machine to create tables but the tables were still owned by the initiating user. (Why a netrc file is read in the first place I haven't a clue) I know that a shot in the dark. Good luck. Hope you find the problem soon, ---------------------- Bingo Mark! That is what it is. I checked Informix .netrc and found entries with non-informix userid. I replaced all with informix own. And that seems to solve the problem. Anyone has an explaination? Thanks all, Chariya Mark -- "Mingle some brief folly with your wisdom." -- Horace Fcc: ~/Mail/outgoing.March-2004