Hi, I recently updated our server to Slackware 14.2 and Luckybackup 0.4.8. Everything works as expected and the scheduled backup is done daily as a cron job. The email facility (sendEmail) sends a test email ok, also if I run a backup manually an email is delivered. However, when a scheduled backup is run, the backup is done but the email fails. Looking at the logs the error message is:
Command: sendEmail
Exit code: 0
Output: Permission denied
The error message is the same whether a user is logged in or not. The backup system worked perfectly before the updates. Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My first guess is that sendemail, when run from cron, has somehow lost permission on a directory or file, it uses.
My second guess is that LB was updated from 0.4.7 to 0.4.8 and the email dialogue was "improved". The new version uses different fields for the command and the arguments.
Could you please make sure that these fileds look ok at the version you are using at the moment
Also, please let me know whether you run LB (and schedule it of course) as a simple user or as root.
The next step is to edit the sendemail arguments so as not to attach a logfile (just remove the "-a %l" argument). Does this work when scheduled or do you still get the permission error message ?
If the above didn't work (I don't have much hope anyway) let me know how comfortable you are, using the terminal and manualy editing crontab so that I provide guidelines to make sendemail run with increased verbosity so that we produce a more detailed logfile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Loukas,
Thanks for your reply. I have been running and scheduling LB as 'root'. The fields in the email dialogue look ok to me, here they are: -xu server@xxxxxxxxxxx.com -xp xxxxxxxxx -f %f -t %t -u %s -m %b -a %l -s %v. I added the -xu and -xp to see if they were the problem (they weren't). I have removed the -a %l field and run an unscheduled backup, this went fine and sent an email. The scheduled run takes place overnight so I'll let you know the result tomorrow.
I'm definitely willing to have a go at manually editing crontab. Thanks for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Loukas, Follow up from yesterday, the email failed again last night. Looking at the logs everything ran and completed ok, the email failed with the same error message.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
all right then, I was thinking of running a sendemail command, with increased verbosity, at first through a terminal and if that works fine, try through crontab and then inspect the logfile. Hopefully there will be a more detailed explanation of what happens.
Type a sendemail command with the "-v" argument added for increased verbosity, at a terminal and run it. This command should have the very same arguments as the one that is run through luckybackup.
You should also run this command as root.
the hash in the beginning is root's prompt
-f from
-t to
-u subject
-m body
-a The full path of an existing LB logfile at root's home directory
-s smtp server
/root/sendemail.log is a logfile that is going to be created, containing the output of the command. I used root's home directory but you can use whatever suits you best.
You can test the command without "> /root/sendemail.log &2>1" in the beginning. Everything will display at the time of the run.
If you inspect the created logfile (eg # cat /root/sendemail.log) after you run this command, normally it should be saying that everything worked fine in a hell lot of detail.
Nevertheless, let me know if that is not the case.
Now copy the above command at root's crontab.
You can edit your current crontab with the command (always as root): # crontab -e
normally your terminal will be setup to run a text editor like “nano”
If “nano” detects changes, when you hit the ctrl+x keys, it will ask you to save changes and replace the existing files.
Of course if you are familiar some other way of manually editing your crontab, please feel free to use that instead.
eg add the following line at the end of the crontab file:
Got the sendEmail command to work from the terminal, the logfile has been created and has lots of detail in it. I've added the command to my crontab, waiting for it to run now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did the cronjob start at all ?
What are the contents of the logfile ?
If the cronjob started, the logfile should have been updated.
Also, could you let me know of the crontab line you used ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't tell if the cronjob ran, there isn't anything in /var/log/cron, not sure where else to look. The logfile is blank which suggests to me it did run as when I've run the command manually there is lots of info in there.
Here's my crontab line:
Please excuse me for editing your post Jerry but the stars looked wrong again due to some formating rules of this forum.
I just checked your command to my system both as root ans as simple user.
I tried with sendEmail and /usr/bin/sendEmail.
I tried to not leave a blank line at the end of the file.
Everything I did, it worked !!
Jerry, could you please give it another try with a simple command like "ls" to confirm that cron is working:
#cron test
20 20 * * * ls > /root/sendEmail.log &2>1
#end cron test
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've run the "ls" command as you suggested and that works fine. I ran it several times both when logged in and logged out, it ran perfectly writing the log file as expected. So cron appears to be working.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bummer :(
Let's give up the manual crontab editing for now [mainly cause I cannot figure out what is wrong :) ] and add the "-v" option directly to the LB email dialogue.
eg change the arguments field from:
-f %f -t %t -u %s -m %b -a %l -s %v
to:
-v -f %f -t %t -u %s -m %b -a %l -s %v
This will provide a more detailed output than just "permission denied"
(why didn't I think of that before ??)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry about the break.
I put the -v in. When I run a test email it produces a verbose log as expected. When the scheduled backup is run the email log is the same non verbose log:
Command: sendEmail
Exit code: 0
Output: Permission denied
Very confused!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SendEmail is located at /usr/local/bin so I had alreadyb put a symlink in at /usr/bin, thinking cron may not be finding sendEmail, so:
bash-4.3# ls -l /usr/bin/sendEmail
total 0
lrwxrwxrwx 1 root root 24 Aug 13 14:10 sendEmail -> /usr/local/bin/sendEmail
but then there is:
bash-4.3# ls -l /usr/local/bin/sendEmail
-rwxr-xr-x 1 root root 80213 Sep 29 2009 /usr/local/bin/sendEmail
So group users and 'other' users only have read access, but it turns out that the group it belongs to is 'root', so maybe there's a conflict here.
I have changed the permissions to:
bash-4.3# ls -l /usr/local/bin/sendEmail
-rwxrwxrwx 1 root root 80213 Sep 29 2009 /usr/local/bin/sendEmail
and I'll see if that does it. Thanks again for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Loukas, That's it fixed. I put the full sendEmail path in the cron command: /usr/local/bin/sendEmail as you suggested and the automatic emails started flowing. Both the scheduled LuckyBackup email and the test cronjob that I set up too. I've been monitoring it for a few days now and all is good. Thank you very much for all your assistance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I recently updated our server to Slackware 14.2 and Luckybackup 0.4.8. Everything works as expected and the scheduled backup is done daily as a cron job. The email facility (sendEmail) sends a test email ok, also if I run a backup manually an email is delivered. However, when a scheduled backup is run, the backup is done but the email fails. Looking at the logs the error message is:
Command: sendEmail
Exit code: 0
Output: Permission denied
The error message is the same whether a user is logged in or not. The backup system worked perfectly before the updates. Any ideas?
Hi Jerry,
My first guess is that sendemail, when run from cron, has somehow lost permission on a directory or file, it uses.
My second guess is that LB was updated from 0.4.7 to 0.4.8 and the email dialogue was "improved". The new version uses different fields for the command and the arguments.
Could you please make sure that these fileds look ok at the version you are using at the moment
Also, please let me know whether you run LB (and schedule it of course) as a simple user or as root.
The next step is to edit the sendemail arguments so as not to attach a logfile (just remove the "-a %l" argument). Does this work when scheduled or do you still get the permission error message ?
If the above didn't work (I don't have much hope anyway) let me know how comfortable you are, using the terminal and manualy editing crontab so that I provide guidelines to make sendemail run with increased verbosity so that we produce a more detailed logfile.
Hi Loukas,
Thanks for your reply. I have been running and scheduling LB as 'root'. The fields in the email dialogue look ok to me, here they are: -xu server@xxxxxxxxxxx.com -xp xxxxxxxxx -f %f -t %t -u %s -m %b -a %l -s %v. I added the -xu and -xp to see if they were the problem (they weren't). I have removed the -a %l field and run an unscheduled backup, this went fine and sent an email. The scheduled run takes place overnight so I'll let you know the result tomorrow.
I'm definitely willing to have a go at manually editing crontab. Thanks for your help.
Hi Loukas, Follow up from yesterday, the email failed again last night. Looking at the logs everything ran and completed ok, the email failed with the same error message.
all right then, I was thinking of running a sendemail command, with increased verbosity, at first through a terminal and if that works fine, try through crontab and then inspect the logfile. Hopefully there will be a more detailed explanation of what happens.
You should also run this command as root.
eg
# sendemail -v -f "jerry@barker.com" -t "jerry@barker.com" -u "subject" -m "test message" -a "/root/.luckyBackup/logs/<LOGFILE.LOG>" -s mailgate.barker.com > /root/sendemail.log &2>1Of course replace all arguments with valid ones:
/root/sendemail.log is a logfile that is going to be created, containing the output of the command. I used root's home directory but you can use whatever suits you best.
You can test the command without "> /root/sendemail.log &2>1" in the beginning. Everything will display at the time of the run.
If you inspect the created logfile (eg # cat /root/sendemail.log) after you run this command, normally it should be saying that everything worked fine in a hell lot of detail.
Nevertheless, let me know if that is not the case.
You can edit your current crontab with the command (always as root):
# crontab -enormally your terminal will be setup to run a text editor like “nano”
If “nano” detects changes, when you hit the ctrl+x keys, it will ask you to save changes and replace the existing files.
Of course if you are familiar some other way of manually editing your crontab, please feel free to use that instead.
eg add the following line at the end of the crontab file:
12 20 * * * /usr/bin/sendemail -v -f "jerry@barker.com" -t "jerry@barker.com" -u "subject" -m "test message" -a "/root/.luckyBackup/logs/<LOGFILE.LOG>" -s mailgate.barker.com > /root/sendemail.log &2>1Make sure to leave a blank line (just press ENTER) at the end of the file.
The first 2 numbers mean “run the following command at 20:12 and the stars mean every day, so use some time a few minutes ahead to not wait long.
Now (after the command is supposed to have run through cron), inspect the logfile.
How did it go ?
wish you luck :)
I forgot to mention that you can always check your current crontab with:
Got the sendEmail command to work from the terminal, the logfile has been created and has lots of detail in it. I've added the command to my crontab, waiting for it to run now.
Waited for the cron job to run... but nothing. Rechecked the sendEmail command and that's ok. So does this mean the problem lies with cron?
Did the cronjob start at all ?
What are the contents of the logfile ?
If the cronjob started, the logfile should have been updated.
Also, could you let me know of the crontab line you used ?
I can't tell if the cronjob ran, there isn't anything in /var/log/cron, not sure where else to look. The logfile is blank which suggests to me it did run as when I've run the command manually there is lots of info in there.
Here's my crontab line:
cron test
20 20 * * sendEmail -v -f "server@***.com" -t "jerry@.com" -u "test message" -a "/root/.luckyBackup/logs/Server_Backup-email.log" -m "test message" -s mail.**.com > /root/sendEmail.log &2>1
end cron test
This is the first cronjob I've set up manually so there could well be an error. Thanks for your help!
...just to make sure, there seems to be a star missing from
it should be
Doh.. here's what it's set to now, still no joy though:
code format, edited by Loukas
Last edit: Loukas Avgeriou 2016-11-02
Please excuse me for editing your post Jerry but the stars looked wrong again due to some formating rules of this forum.
I just checked your command to my system both as root ans as simple user.
I tried with sendEmail and /usr/bin/sendEmail.
I tried to not leave a blank line at the end of the file.
Everything I did, it worked !!
Jerry, could you please give it another try with a simple command like "ls" to confirm that cron is working:
I've run the "ls" command as you suggested and that works fine. I ran it several times both when logged in and logged out, it ran perfectly writing the log file as expected. So cron appears to be working.
bummer :(
Let's give up the manual crontab editing for now [mainly cause I cannot figure out what is wrong :) ] and add the "-v" option directly to the LB email dialogue.
eg change the arguments field from:
to:
This will provide a more detailed output than just "permission denied"
(why didn't I think of that before ??)
Sorry about the break.
I put the -v in. When I run a test email it produces a verbose log as expected. When the scheduled backup is run the email log is the same non verbose log:
Command: sendEmail
Exit code: 0
Output: Permission denied
Very confused!
looks like the command didn't run at all then !
Could it be that root via cron somehow does not have permission to run sendEmail ?
Could you please :
locate sendEmailthis will result in something like:
and then use the first line of the above output to issue an ls command eg:
ls -l /usr/bin/sendEmailWhat is the output of the last command ?
Last edit: Loukas Avgeriou 2016-11-10
SendEmail is located at /usr/local/bin so I had alreadyb put a symlink in at /usr/bin, thinking cron may not be finding sendEmail, so:
bash-4.3# ls -l /usr/bin/sendEmail
total 0
lrwxrwxrwx 1 root root 24 Aug 13 14:10 sendEmail -> /usr/local/bin/sendEmail
but then there is:
bash-4.3# ls -l /usr/local/bin/sendEmail
-rwxr-xr-x 1 root root 80213 Sep 29 2009 /usr/local/bin/sendEmail
So group users and 'other' users only have read access, but it turns out that the group it belongs to is 'root', so maybe there's a conflict here.
I have changed the permissions to:
bash-4.3# ls -l /usr/local/bin/sendEmail
-rwxrwxrwx 1 root root 80213 Sep 29 2009 /usr/local/bin/sendEmail
and I'll see if that does it. Thanks again for your help.
Well damn, thought it was solved there for a while. but no.
...just to make sure, could you try to use the full path of the sendEmail command
[this must be the 100th trial !!]
Hi Loukas, That's it fixed. I put the full sendEmail path in the cron command: /usr/local/bin/sendEmail as you suggested and the automatic emails started flowing. Both the scheduled LuckyBackup email and the test cronjob that I set up too. I've been monitoring it for a few days now and all is good. Thank you very much for all your assistance.