0

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?

3
  • 2
    networksetup requires at least admin and maybe root depending on how the system is configured in order to change anything. Who's crontab are you entering it in? Why do you need to schedule turning it on anyway, vs just leaving it on? May 25, 2021 at 1:45
  • It doesn't generally require root (in High Sierra at least), I expect it needs to be run by a user that is able to select a wifi network on the desktop. I too have just been trying to run it via cron, as if my wifi network restarts then MacOS will not always reconnect. Inconvenient for a Mac mini without screen or keyboard.
    – jrg
    May 26, 2021 at 15:34
  • Hi Marc, to answer your question I'm entering it into my own crontab. I have admin privileges and as for root, I did try entering the command in sudo crontab, but this didn't work either. The reason for needing to schedule this command is my Wifi access point is not functioning properly, and it turns off at random. This is an issue when my mac is downloading/uploading files while unattended.
    – Zane
    May 27, 2021 at 23:44

2 Answers 2

2

In addition to possible permissions problem, you might be having trouble because networksetup isn't in the default PATH for cron jobs. The default path for cron jobs includes just /bin and /usr/bin, but the networksetup executable is in /usr/sbin, so the command will not be found.

To prevent this problem, you can use an explicit full path for the command:

05 15 * * * /usr/sbin/networksetup -setairportpower en0 on

Another option is to adjust the PATH variable in the crontab file (before the command that depends on it), something like this:

PATH=/usr/bin:/bin:/usr/sbin:/sbin
05 15 * * * networksetup -setairportpower en0 on

Also, when troubleshooting cron jobs, it's often very helpful to capture errors and output from the jobs in some easily-accessible place, and then examine them to see what they indicate. You can capture them with a redirect, something like this:

05 15 * * * /usr/sbin/networksetup -setairportpower en0 on >>/tmp/cronjob.log 2>&1

...and then look at /tmp/cronjob.log after the job runs.

1
  • Hi Gordon, thanks so much for answering this question from five months ago. Luckily, I did some more research at the time and got the command to work by doing exactly what you suggest- using the full path command. And thanks for the advice regarding troubleshooting, I will use it when needed in the future.
    – Zane
    Nov 1, 2021 at 21:08
0

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).

3
  • "Operation not permitted" indicates that the user is not privileged to run the program.
    – fd0
    May 26, 2021 at 18:00
  • Hi Jrg, how were you able to check your logs for cron jobs? I tried to run it from root's crontab, but that hasn't worked either.
    – Zane
    Jun 7, 2021 at 22:15
  • Yes.. I seems to reconnect fine most of the time (as I noted, it had worked as my own user a couple of times, before then failing). I’m doing it on a system running Mojave (10.13). I’ll update my post later with the script I’m using.
    – jrg
    Jun 9, 2021 at 11:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .