Why is Cron not running the enable wifi command

command linecronterminalwifi

I'm trying to use crontab to schedule the 'enable wifi' command: networksetup -setairportpower en0 on.

I've been entering this command in the required format in the cron file, eg.:

05 15 * * * networksetup -setairportpower en0 on

However, it isn't working. This command works when I use it normally, and I've used crontab to successfully run other commands. Why is the command not running as intended, and what should I do to fix it?

Best Answer

I'm trying to get something similar to work too (using the -setairportnetwork option)

My WiFi access point is misbehaving, and sometimes restarts. When it does that, many of my MacOS systems do not automatically reconnect, and this is very inconvenient for my Mac mini that does not have a keyboard, mouse, or ethernet attached.

From the networksetup "man" page (man networksetup)

The networksetup command requires at least admin privileges to change network settings. If the "Require an administrator password to access system-wide preferences" option is selected in System Preferences > Security & Privacy, then root privileges are required to change network settings.

But I expect there's something different about the context in which cron runs a user's job than when it runs whilst logged into the desktop.

In my case, when it fails it outputs the following:

Error: -3930  The operation couldn’t be completed. (com.apple.wifi.apple80211API.error error -3930.)

and the only place I can find error "3930" documented is in Jonathan Levin's "new OS X Book" notes, unfortunately "Operation not permitted" isn't much to go on.

Perhaps Marc is indeed thinking in the right direction, at least that if not running interactively as a "Desktop" user then it needs to run as root. Going to try that, next, and report back...

Update (20210603)

When I looked more closely at my logs I saw that it had successfully re-associated to the network at least once or twice before failing with the above error: to reiterate, that was when running from my own user crontab.

But, I did switch to running it from root’s crontab and it has worked successfully several times since then. So I’d definitely suggest trying that (sudo crontab -e being the way I went about doing that).

Related Question