How to fix “Bad minute” error while installing a new crontab

Each crontab line must start with a time at which the command should be run and then the command. The general format is:

Min Hour Day Month DayOfWeek Command

So, to run command at 10:15 every Sunday, you'd do:

15 10 * * 0 command

I'm not sure what your commands are, but you have lines that don't start with a time definition. I don't understand what lines like this are:

* * * * * /usr/local/ampps/php-5.6/etc

That's a time but no command. You're giving it a directory. And lines like this have commands but no time:

/usr/local/ampps/www/localshop.dev/bin/magento cron:run | grep -v "Ran jobs by schedule" >> /usr/local/ampps/www/localshop.dev/var/log/magento.cron.log

So, make sure you follow the format and you should be fine. If this is not clear, edit your question and explain what commands you are trying to run.

From my previous experience, it was due to a CR/LF character before the first cron line (since it was edited from Windows not Linux directly). I noticed and removed that char from a HEX editor.

This error also happens if your /var/spool/cron partition is 100% full. Check your free disk space and make sure you have a few bytes free there.

This kind of error may also occur if you are trying to reset cron variables to empty values like this:

[email protected]
* * * * * do some stuff with error reporting
MAILTO=
* * * * * do another stuff too verbose to receive emails

Note the empty line after MAILTO= at line 3. This will result in the message:

crontab: installing new crontab
"/tmp/crontab.AvDwzo":3: bad minute
errors in crontab file, can't install.
Do you want to retry the same edit? 

The correct way to reset MAILTO variable is to use empty quotes, like this:

MAILTO=''

Hope this helps.

In my case (and it seems to be OP's case as well), the issue was that I had a new line in the command to be executed, something like this

5 0 * * * some_command -some_param
-another_param

The overflowing line was of course interpreted as a new cron entry, and cron rightfully complained that the start of that line was not a valid minute identifier.