I've done a mysqldump from our Drupal6/CiviCRM4 Civi DB and am trying to import it into a Drupal7/Civi4 dev install, but keep getting "ERROR 1227 (42000) at line 369: Access denied; you need the SUPER privilege for this operation"
From what I can tell, user has correct permissions as indicated via site's cpanel, all appears correct in the import command. I've not come upon this error before doing similar proceedures on other installs. Help please?
It could be one of a couple of things.
First, if you have MySQL version before 5.1.6, you'll need the SUPER permission no matter what:
http://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+MySQL+Permission+Requirements
However, since it has been running fine and you're just trying to import the dump file, I think it's probably that your dump file has functions where the definer is set as the database user for the old site (let's say "foo#localhost"). You aren't allowed to set the definer as someone other than yourself without the SUPER privilege. If the new site has a different user (maybe "bar#localhost"), you're acting as "bar#localost" trying to set a function defined by "foo#localhost".
In your dump, you'll probably see something along the lines of
CREATE DEFINER=`foo`#`localhost` FUNCTION ...
You can do one of two things:
have both databases use the same database user account, or
edit the dump file to replace the old user name with the new user name everywhere it occurs.
You should also be aware that "foo#localhost" and "foo#%" are separate users, even if they have the same name and password.
A Drupal/CiviCrm database uses triggers. The SUPER privilege is needed to recreate the trigger when you import the database. If you've restricted your standard user's privileges to those needed while running Civi, you can create a new MySQL user just for the import and grant that user ALL privileges on the database(s). After the import is complete, remove the user with elevated privileges.
Related
I have tried for hours to get around this.
I can confirm the database is running, the tables are there, the user 'acore' is created, the password is set correctly and the user has permissions to the acore_auth, world and characters tables, yet no matter what I do, the db_assembler.sh script refuses to run, claiming that the user acore has been denied access.
Heidi SQL Screenshot showing acore user permissions
Resolved:
A prior step in the instructions refers to copying the config.sh file from /azerothcore/conf/dist to /azerothcore/conf and amending it as needed for any SQL information different from the default (I was using port 3308 instead of port 3306). I did that and amended the new config.sh file however the db_assembler.sh script was still looking at the config.sh file in the /azerothcore/conf/dist directory (which had the default settings of 3306).
When I amended THAT file, the import worked perfectly.
Hello to forum from a part time occasional user of MS Access 2010:
Trying to get permission to allow a third party application read MsysObjects which in turn will allow it to save a copy of the table relationship window in a form that will allow the layout to be recovered when it crashes (frequently - and is a known irritation/bug).
Have tried the method suggested in quote from this forum [HansUp] without success - including substiting this DAO line for the last ADO line following advice on a different forum:
dbEngine(0)(0).Execute strDdl, dbFailOnError
Since your db is ACCDB format, you will be working as user Admin. You can confirm that point in the Immediate window. (Go there with Ctrl+g)
? CurrentUser()
Admin
Since Admin doesn't have read (SELECT) permission on MSysObjects, execute a DDL statement to give Admin that permission.
strDdl = "GRANT SELECT ON MSysObjects TO Admin;"
CurrentProject.Connection.Execute strDdl
Advice from yet another forum to import or export to fresh blank accdb gives no result as permissions are still not available.
All this is beyond my pay grade so any advice welcome.
On a RedHat 6 server, a third party application requires to be root to run and needs access to sqlplus. I have a running database, I can run sqlplus as user 'oracle'. When logged in as user root, 'sqlplus usr/pwd#dbname' works as expected. The trouble is that this agent needs to run sqlplus with no parameters and it always returns ORA-12546: TNS:permission denied.
I've read a dozen times that enabling root to launch Oracle is a security issue but I really have no other choice.
Running Oracle 11.2.0.1.0.
Any help will be much appreciated as I've googled for 2 days with no success.
From the documentation, ORA_12546 is:
ORA-12546: TNS:permission denied
Cause: User has insufficient privileges to perform the requested operation.
Action: Acquire necessary privileges and try again.
Which isn't entirely helpful, but various forum and blog posts (way too many to link to, Googling for the error shows a lot of similar advice) mention permissions on a particular part of the installation, $ORACLE_HOME/bin/oracle, which is a crucial and central part of most of the services.
Normally the permissions on that file would be -rws-r-s--x, with the file owned by oracle:dba, and this error can occur when the word-writable flag - the final x in that pattern - is not set. Anyone in the dba group will still be able to execute it, but those outside will not.
Your listener seems to be fine as you can connect remotely, by specifying #dbname in the connect string. The listener runs as oracle (usually, could be grid with HA, RAC or ASM) so it is in the dba group and can happily hand-off connections to an instance of the oracle executable.
When you connect without going via the listener, you have to be able to execute that file yourself. It appears that root cannot execute it (or possibly some other file, but this is usually the culprit, apparently), which implies the world-writable bit is indeed not set.
As far as I can see you have three options:
set the world-writable bit, with chmod o+x $ORACLE_HOME/bin/oracle; but that opens up the permissions for everyone, and presumably they've been restricted for a reason;
add root to the dba group, via usermod or in the /etc/group; which potentially weakens security as well;
use SQL*Net even when you don't specify #dbname in the connect string, by adding export TWO_TASK=dbname to the root environment.
You said you don't have this problem on another server, and that the file permissions are the same; in which case root might be in the dba group on that box. But I think the third option seems the simplest and safest. There is a fourth option I suppose, to install a separate instant client, but you'd have to set TWO_TASK anyway and go over SQL*Net, and you've already ruled that out.
I won't dwell on whether it's a good idea to run sqlplus (or indeed the application that needs it) as root, but will just mention that you'd could potentially have a script or function called sqlplus that switches to a less privileged account via su to run the real executable, and that might be transparent to the application. Unless you switch to the oracle account though, which is also not a good idea, you'd have the same permission issue and options.
I have got most of the way but there seems to be a permissions issue somewhere:
Before the restore everything is working fine in my target environment - target has a server login account TCMDBUser which is mapped to my tridion_cm database user TCMDBUser
My source tridion_cm database has user TCMDBUser_DEV.
After restoring the source .bak into my target TCMDBUser_DEV is orphaned.
I edit the TRUSTEES table to correct MTSUser and my admin log accounts for my target environment and run the following to fix up my orphaned database user:
sp_change_users_login #Action='update_one',
#UserNamePattern='TCMDBUser_DEV',
#LoginName='TCMDBUser'
GO
I can log back in to Tridion explorer and see the expected list of publications and can walk through the tree structure but when I come to a folder which should contain items I see nothing with error:
and the corresponding event log error is:
Unable to get list of SDL Tridion Content Manager items.
DESCRIPTION
Error Code:
0x80040000 (-2147221504)
Call stack:
System.Data.ProviderBase.FieldNameLookup.GetOrdinal(String)
System.Data.SqlClient.SqlDataReader.GetOrdinal(String)
System.Data.SqlClient.SqlDataReader.get_Item(String)
Tridion.ContentManager.Data.AdoNet.DatabaseUtilities.ConvertToFieldDictionary(IDataRecord,IDictionary`2)
Tridion.ContentManager.Data.AdoNet.IdentifiableObjectDataMapper.Read(TcmUri,IDataRecord,IDictionary`2)
Tridion.ContentManager.Data.AdoNet.ContentManagement.OrganizationalItemDataMapper.GetListItemsPost(IDataReader,TcmUri,OrganizationalItemItemsFilterData)
Tridion.ContentManager.Data.AdoNet.ContentManagement.OrganizationalItemDataMapper.Tridion.ContentManager.Data.ContentManagement.IOrganizationalItemDataMapper.GetListItems(TcmUri,OrganizationalItemItemsFilterData)
Tridion.ContentManager.ContentManagement.OrganizationalItem.GetListItemsData(OrganizationalItemItemsFilter)
Tridion.ContentManager.ContentManagement.OrganizationalItem.GetListItemsStream(OrganizationalItemItemsFilter)
Tridion.ContentManager.BLFacade.ContentManagement.OrganizationalItemFacade.GetListItemsXml(UserContext,String,ListFilter,ListColumnFilter)
Tridion.ContentManager.BLFacade.ContentManagement.OrganizationalItemFacade.GetListData(UserContext,String,EnumListKind,ListColumnFilter,String)
Folder.GetListItems
You will need to delete/drop the TCMDBUser_DEV form the DB and then create a new one with the same name and password (or reattach it to your cm DB). That should fix your problem.
I normally use the delete method with MS SQL server. I believe this occurs due to the ownership status that the TCMDBUser has on the database Schema.
When complete your TCMDBUser user should have the following permissions on your Tridion_CM database
Like Chris mentioned, I always drop the user from the database and then assign the existing TCMDBUser in SQL Server the rights to the restored database. You can drop the user with the following command (on the restored database):
EXEC sp_dropuser TCMDBUser
Then through the SQL Server - Security - Logins, you request the properties of your TCMDBUser and in the User Mapping add the following database roles: db_datareader, db_datawriter and db_ddladmin.
That's what I've always done in the past and works for me, not sure if its all required, but worth a try I guess
Try creating new user TCMDBUser in the database and run the following command
EXEC sp_change_users_login 'Update_One', 'TCMDBUser', 'TCMDBUser'
Database i am using is MySQL 5.1. I specified, i believe, right connectionstring in my web.config. but when i run my web app. it throws this exception:-
MySql.Data.MySqlClient.MySqlException: The user specified as a definer ('root'#'%') does not exist
Any help. Why am i getting this?
The source code for the stored procedures that you have been loading probably contain "DEFINER=root#'%'" as part of the definition - looking a bit like this:
create definer='root'#'%' procedure sp_test() begin end;
The problem here is that you do not have an account on your system for 'root'#'%'. This can be easily demonstrated. From the MySQL command line:
show grants for 'root'#'%';
I expect that this will come back with an error message:
ERROR 1141 (42000): There is no such grant defined for user 'root' on host '%'
The fix is to alter the source of your stored procedures, or to create the missing account:
grant all on *.* to 'root'#'%' identified by 'password' with grant option;
It is not generally a good idea to have such a high-powered account accessible from anywhere, but that is another story.
I know this answer comes very late, but I found a solution that doesn't involve changing any rights at all.
Go into your Stored Procedures and delete the DEFINER clause. The server should write in a new DEFINER that matches the user information you're logged in with.
Worked for me...
Is this in a stored procedure? Then maybe this blog post helps (emphasis mine).
All the settings were fine and I was wondering what’s causing the problem. At first rush I thought that it could be a cache, as I had requested recently to have xcache on our server.
But it wasn’t the case. The error was much more stupid than even one can imagine. That specific script uses a stored procedure to insert / fetch data to/from MySQL. The user who had created the sp was the one who was deleted. And that was the problem. The term “Definer” in terms of MySQL is the one who creates the stored procedure and for the stored procedure to be executed that user must exists.