>>> After working happily for many years, part of an application started
>>> failing with the following messages:
>>> Program stopped at "temp_sth.4gl", line number 19. SQL statement
>>> error number -261.
>>> Cannot create file for table (dirwatch.temp_sth). SYSTEM error number
>>> Not owner
>> Errno = 1 is 'Not owner' as the 4GL diagnostic indicated. Perhaps the
>> ownership of the database.dbs directory was accidentally changed.
> The permissions look like:
> drwxrwx--- dbuser dbgroup dbname.dbs
That's dubious; the group should be informix. Then dbuser would own
the database, but the SGID informix program sqlexec would be able to
access the files in the database directory - and create them, etc.
Quote:> When I log on as dbuser (primary group dbgroup) and run the app that
> does "create temp" I get the error message. programs that create and
> drop permanent tables work fine.
Where are the temp tables being created? Where does $DBTEMP point to?
What are the permissions on /tmp and /usr/tmp?
Quote:> I found that $INFORMIXDIR/bin/changrp was owned by "informix", chowning
> this to "root" makes the problem go away:
> -rwsr-sr-x 1 root informix /u/rds420/bin/changrp
That would certainly help. $INFORMIXDIR/etc/sefiles lists all the
files in the distribution and the owner, group and permissions that
should be set on the files. There's a toolkit in the IIUG Software
Archive, utils_jl, which has tools ixchkperm and ixsetperm to sort out
permissions problems. The permissions on $INFORMIXDIR/lib/sqlexec are
also extremely important (owner root, group informix, 6755 - though
6711 or 6511 or 6111 would also be OK; the 6 indicates SUID and SGID).
Quote:> But could the real problem be with ownership and permissions for
> systables.dat and systables.idx?
In part - but not for temporary tables since they are not detailed in
the system catalog. The owner of the system catalog should be either
informix or the database owner, the group should be informix, and the
permissions should be 660.
>>> The relevant part of temp_sth.4gl is
>>> CREATE TEMP TABLE temp_asset
>>> sth_asset_ref CHAR(20)
>>> Software is I4GL 4.20 RDS and SE 5.10 on SCO OSR 505
>>> The /tmp filesystem is not full up and setting DBTEMP doesn't help.
>>> permissions on /tmp are normal. The code works OK on another OSR 505
So what are the permissions on /tmp? 777, possibly with the sticky
bit set (1777).
>>> Permanent tables can be created and dropped OK
>>> Does anyone have any ideas what might cause this problem?
I think you've got the answer - permissions.
You might try to find out who changed the permissions on the system
and why, because they're likely to do it again, and then you'll have
to fix it again. It is usually an over-zealous sys admin removing SUID
root programs from the system who does the damage.
Jonathan Leffler #include <disclaimer.h>
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/