Open firebird-automations opened 12 years ago
Commented by: @paulbeach
Not true. What happened in this case is that your initial access to the database was via a local connection with a user that was not part of the firebird group. As such the ownership of the lock files etc defaulted to this user. In future either connect initially using either localhost or the host name first or make sure that any user who connects to firebird directly is part of the Firebird group. Ownership of the lock files etc should belong either to the user who created them or to firebird for security reasons.
Commented by: Maury Markowitz (maury.markowitz_gmail.com)
I am not sure about what the comment is saying, but here is the connections string used in this case:
localhost:/Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employee.fdb
Is this not matching "either localhost or the host name first"?
Commented by: @paulbeach
There are essentially two ways to acess a firebird database, via the remote access method using either the host name, IP address or localhost, and you can also access Firebird using the embedded method by just specifying the local database name on disk. As I pointed out earlier, the only way to generate the ttype of error you are seeing above is to use the embedded access before using remote. Embedded will adopt your user name/group characteristics which cannout be shared by the normal user/group allocated to firebird for remote access. If you used localhost as the first attempt to access a database then all will work. If you want to use embedded then at a later data, add your local user to the firebird group. When I test the install of every build, I use a script to delete all traces of Firebird from my Mac, and this includes deleting the firebird user and group. If there was such a basic install problem, I suspect I or someone else would have noticed it by now.
Commented by: Maury Markowitz (maury.markowitz_gmail.com)
I remain confused. Let me describe exactly the steps I followed that caused this error to occur, and maybe you can point out where the problem came in.
1) I installed FB on my Mac under my (the only) account 2) I ran isql from my account to test that the DB was installed properly 3) I immediately got the error when trying to test ODBC 4) I deleted the /tmp/firebird dir and things started working for ODBC
wait...
a) I svn'ed the latest version of ODBCQueryTool and re-tested a bug in the ODBC side I've been trying to solve. b) I downloaded and installed the DMG the latest version of the entire ODBCKit package c) the error re-appeared
I can see how the numbered steps led to the problem, but I don't believe the lettered series should have caused it again. Nothing else changed between these runs, they were literally seconds apart.
Commented by: @paulbeach
Give me a simple reproducable test case or try the support list. At the moment I don't see how this can be a bug.
Submitted by: Maury Markowitz (maury.markowitz_gmail.com)
Installing using the Mac installer uses a new userid for all file ownership and permissions that makes the system unusable out of the box.
1) the permissions/ownership on /tmp/firebird are set such that the system is in an unusable state:
Statement failed, SQLSTATE = HY000 Can't access lock files' directory /tmp/firebird
The directory must be deleted by hand in terminal.
2) the permissions/ownership of everything else likewise leaves the system in an unusable state:
Statement failed, SQLSTATE = 28000 no permission for read-write access to database /Library/Frameworks/Firebird.framework/Versions/A/Resources/examples/empbuild/employee.fdb
The user must chown or set permissions for everyone read/write to get even the example DB to work.