mysqldump fails for non-root shell user
Hello All,
I've been searching and searching and searching for an answer to this problem but can't seam to find an answer anywhere!
Problem:
A non-root hosted cPanel account user with regular shell access gets permission denied when trying to use mysqldump
"-bash: dbbackup.sql: Permission denied"
The user can successfully log into any of their databases with mysql (using: mysql -u username -p database_name) but no use of mysqldump - response says bash permission denied!
Is there a way to give normal shell non-root cPanel user accounts the ability to use mysqldump? I can't find anything on extending privileges to shell users (other than making them a sudo user and adding them to the wheel group) but I don't want to give them the ability to execute commands that could be a security risk - I just want to give regular shell accounts the ability to use mysqldump for their databases.
- I've been having to login as server root user to create a mysql backup using dump for several users (and it's getting to be a pain)
- Most users are fine without shell to backup their databases having phpMyAdmin, however there are a couple accounts with excessively large databases and phpMyAdmin fails, so shell with mysqldump is required for database backup on those accounts.
-Accept I can't find documentation on adding functions, features or commands to shell for users.
Any help here would be greatly appreciated!
~Thank You
-
Hello, Could you let us know the specific "mysqldump" command you are using? Also, can you verify if this system uses CloudLinux with CageFS? Thank you. 0 -
Hi cPanelMichael, command used: mysqldump -u username -p database_name > db_backup.sql
If I run it as the root user or user with root permissions that works perfectly. But when logged in as the user through their shell access -bash permission denied. And yes CloudLinux 6.9 user account is in CageFS ~Thank You0 -
mysqldump -u username -p database_name > db_backup.sql
Hello, Check to see what your current working directory is when logged in via SSH as the account username. EX:pwd
If it's outside of /home/$username, then mysqldump won't be able to write that SQL backup file. To allow that command to work, first switch to the account's home directory:cd /home/username
Or, update your command so the destination path is defined as:/home/username/db_backup.sql
Thank you.0 -
Hello, Check to see what your current working directory is when logged in via SSH as the account username. EX:
Got it - and I'm pretty sure I know what the problem was now (thanks to your suggestion) Originally I had logged in as a root user when dealing with some support ticket for client cPanel accounts (phpMyAdmin was failing do to the size of there DB's as they were nearing the 1G mark) So I created a folder in there public_html directory called dbdump - where it was easiest for them to download the backup via FTP connection, which worked out fine they didn't have any problems. But what I think happened was because the root user created the directory - because I originally gave them instructions on how to do the mysqldump themselves listing that directory "dbdump" in the path (basically made them a cut and paste code snippet, which includes gzip) - And that's were permission denied hit... Per your advice I just did a quick test logging in as the client which was directly into there /home/username [~] directory and ran the command and it worked, so I then created a new directory db-dump under public_html and all worked as should. (Also just realized I will now have to delete the original dbdump directory logged in as root admin, cause I received a permission denied trying to remove it as the account user) - Yep permissions, and makes complete sense.. Thank you for the assist cPanelMichael - most appreciated, I didn't run into one post anywhere even mentioning trying a different directory.. I run into an issue like this again in my travels I will try a different directory first.. Thanks again! Felt like I was going in circles trying to search for a solution..0 -
Hello, I'm glad to see that helped solve the issue. Thank you for updating us with the outcome. 0
Please sign in to leave a comment.
Comments
5 comments