At 03:45 AM 3/04/2007, you wrote:

>Hi,
> I'm running classic server on Debian.
> When I restore a database ( gbak -c ), the restored file belongs to
>root. I can connect locally ( isql-fb ), but if I connect remotely I
>receive a permission denied error code.

When you connect locally, you are connecting directly to the database
file and your process is running in the logged-in user's application
space. From your description it appears you were logged-in as root
when you ran gbak. The root user has the same Firebird user powers
as SYSDBA on POSIX systems.

Running applications as root is not something you should ever do for
any applications, Firebird and its tools included. Ideally, for
backups and restores, you should use a local loopback connection and
the -se[rvice] switch and provide a proper set of Firebird server
login credentials.

If you want to do admin stuff via the direct connection then create a
system user that is going to be your database owner/admin, let's say
you name it 'DBADMIN'. That user should be the only one that creates
databases and runs backups and restores. Create a firebird group if
it does not already exist and add DBADMIN to that group.

In your security database, as SYSDBA, create an authentication record
for 'dbadmin'. (Firebird will store it as DBADMIN). Include the
system user name ('DBADMIN') and group (firebird) in the
record. Then make sure that you are logged in as this user whenever
you use the direct connection method.

However, the proper way to have done this restore would have been as
follows (assume we are located at /opt/firebird/bin or wherever
Debian locates the firebird binaries):

./gbak -c -user dbadmin -pas wxyz8765 -se localhost:service_mgr
/data/bkp/mybackup.fbk /data/mydb.fdb

> The only way I found to avoid it is to change manually the *.fdb
>ownership to firebird:firebird and REBOOT the sever (?)
> I tried starting and stoping inetd server, killing fb_ processes,
>but still I can't connect manally.

When you use the direct connect method, inetd is not involved. I
notice you talk about "killing fb_ processes" as a plural. There
should have been only one; and, if the restore had finished
normally, there would not have been any, i.e. there should be no
processes to kill.

If there was still a fb_inet_server process running then it is
probable that the restore had not finished. If there were multiple
processes then you had some kind of a minefield there.

> So my questions are:
>Why does gbak create files belonging to root instead of firebird user ?

See above. Don't connect to databases as root and don't run gbak as root.

>Why should I have to reboot in order to make take efect and ownership
>change ?

If the database file was open at the time you did the chown then the
changes would be deferred until the file was properly closed. If you
saw fb_inet_server processes running then the file was definitely not
closed. Note that disconnecting from the database is the only way to
end a fb_inet_server process normally.

However, if you do things the right way, there won't ever be a need
to alter the ownership of any database file.

Keep the root user right out of the picture. It doesn't belong in
this environment at all. And, if you are planning to do admin stuff
via a direct connection, instead of via [x]inetd, then make sure you
get your user environment properly set up FIRST.

./heLen