Subject | Re: [firebird-support] connection rejected by remote interface |
---|---|
Author | Helen Borrie |
Post date | 2005-09-29T08:03:22Z |
At 06:20 AM 29/09/2005 +0000, you wrote:
UID. Any recognised UID will get this access if it has the requisite file
permissions.
and password. In this case, it is the owner of the fb_inet_server process
(the 'firebird' user) that opens the file in response to a request from a
*firebird user*, i.e. one that has a user name and password in security.fdb.
Now, assuming that the 'firebird' UID or the firebird group has the
required filesystem permissions to the database file *and* has execute
permissions on the directory that the file is in, you should be able to
connect successfully by supplying the full SYSDBA login (or that of another
security.fdb user).
./heLen
>I have just installed FirebirdCS-1.5.2.4731-0.i686.rpm on a new VMwareHere you are doing a direct connection to the database *file* via root's
>virtual machine using SuSE 9.2. I've done this sucessfully a few
>times before. For the life of me, I cannot connect via a remote server.
>
>linux:/home/phil # /opt/firebird/bin/isql
>Use CONNECT or CREATE DATABASE to specify a database
>SQL> connect '/home/zdk/data/TA_REPORTS.GDB';
>Database: '/home/zdk/data/TA_REPORTS.GDB'
UID. Any recognised UID will get this access if it has the requisite file
permissions.
>SQL> connect 'localhost:/home/zdk/data/TA_REPORTS.GDB';Here you are trying to connect to a database via xinet without a user login
>Commit current transaction (y/n)?y
>Committing.
>Statement failed, SQLCODE = -923
>
>connection rejected by remote interface
and password. In this case, it is the owner of the fb_inet_server process
(the 'firebird' user) that opens the file in response to a request from a
*firebird user*, i.e. one that has a user name and password in security.fdb.
Now, assuming that the 'firebird' UID or the firebird group has the
required filesystem permissions to the database file *and* has execute
permissions on the directory that the file is in, you should be able to
connect successfully by supplying the full SYSDBA login (or that of another
security.fdb user).
./heLen