1

I have a script to temporarily mount an SMB share and copy some files that get generated for my team.

It works find locally, but fails to mount the remote share when run from cron. I am not including the script as the commands in question should be evident from the outputs below.

Local operation output:

$ get-reports.sh 
Tue Feb 18 16:14:05 EST 2020
+ whoami
gtarsa
+ id
uid=1234567(gtarsa) gid=1234567(#######) groups=1234567(#######),<usual Apple groups>
+ /sbin/umount /Users/gtarsa/reports
+ /sbin/mount -t smbfs //engsrv/reports /Users/gtarsa/reports
+ find /Users/gtarsa/reports -iname '*gtarsa*' -exec cp '{}' /Users/gtarsa/Downloads/reports ';'
+ /sbin/umount /Users/gtarsa/reports
+ set +x
$

Cron result:

$ cat ~/Downloads/reports/copy.log 
Tue Feb 18 12:20:00 EST 2020
+ whoami
gtarsa
+ id
uid=1234567(gtarsa) gid=1234567(#######) groups=1234567(#######),<usual Apple groups>
+ /sbin/umount /Users/gtarsa/reports
+ /sbin/mount -t smbfs //engsrv/reports /Users/gtarsa/reports
mount_smbfs: server rejected the connection: Authentication error
+ echo '? Unable to mount Reports Share'
? Unable to mount Reports Share
+ exit 1
$

I have tried explicitly specifying connection credentials (as described in man mount_smbfs) with no success. I am running script manually when I need it, but would prefer to have it run periodically on its own.

Something is different in the cron environment from my interactive environment, but I have not been able to discern what. Google searches for answers come up with lots of "How to mount a share from the command line", but not from cron. Ideas and insight welcome.

5
  • It generates an authentication error. How are you passing the username/password? See man mount_smbfs for more details. – Allan Feb 18 '20 at 22:00
  • In this example, I am assuming that what works in my terminal window should work with cron; so, I am not passing any authentication information--it defaults to the correct information in my terminal window. Having said that, I experimented with passing explcit credentials as described in man mount_smbfs. Passing the correct credentials explicitly gives the same error. – Greg Tarsa Feb 18 '20 at 23:37
  • If passing the credentials gives the same error either you have a problem with the credentials or you have an issue with the way the URI is formatted..but I can't tell from all the way over here... – Allan Feb 18 '20 at 23:46
  • What does the cron entry look like? Also what is the path to the cron file? Cron does not run using the same environment as your shell by default. Also, unless otherwise specified cron jobs are usually run as root – TheWellington Feb 19 '20 at 0:56
  • Is the Apple login the same as the login for the SMB server? What if you just do a simple open smb://<smbserver>/share/path? – Allan Feb 19 '20 at 5:00
0

Yes, some things are different in the cron environment from your gtarsa environment. You can check the cron user environment for yourself using this "recipe".

Since you can run your script manually, it seems likely you've set up your Samba passwords and permissions appropriately.

You've chosen not to share your crontab entry, but I've mounted and umounted my Samba shares from a cron script with lines in my crontab like this:

25 * * * * /sbin/mount -t smbfs //user:password@SambaServer/sharename /Users/seamus/SmbSrv01 

35 * * * * /sbin/umount /Users/seamus/SmbSrv01

This assumes a mountpoint declared (mkdir) at /Users/seamus/SmbSrv01

Since the cron user's path is not the same as gtarsa, you should check that you're using full path specifications to everything that's not in the cron user's PATH... or just everything if you're not sure.

Also NOTE: Putting userid and password in a script or a crontab as I've done here is something you should not do. Less insecure is putting the userid and password in ~/.bash_profile; e.g.:

export MOUNTUSERID="some_user" # where "some_user" is you, or a userid with Samba privileges 
export MOUNTUSERPWD="some_passwd" # "some_passwd" is "some_user" Samba password

Add these lines to the bottom of ~/.bash_profile, and use these environment vars with the mount command in your script. Before you run the script, reload ~/.bash_profile to pick up the environment variables you've just declared:

source ~/.bash_profile

<redundant>You've chosen not to share your crontab entry</redundant>, but if you've not already done so you could help yourself by directing stderr from your script to a file for post-mortem analysis. In your crontab:

* * * * * /full/path/to/script >> copy.log 2>&1  

will capture anything output to stderr in the file copy.log

Finally, if you're running your script under the @reboot spec, you should probably put a sleep command before you try to mount.

If none of this helps, please edit your Q to add your crontab entries, and as much of your script as possible and relevant.

4
  • You don't need sudo to issue a mount command. – Allan Feb 19 '20 at 4:59
  • @Allan: I take your point. I think there are cases where sudo is required to successfully execute a mount command, but my Mojave systems seems to be happy without it. I'll revise my answer, and thanks for pointing this out. – Seamus Feb 19 '20 at 7:37
  • Thanks, Seamus, for the complete answer. I experimented with the credentials and learned that, at least in my environment, that the username needs to be explicitly specified, apparently it is different in cron. With an explicit username I found I did not have to specify a password at all. – Greg Tarsa Feb 19 '20 at 18:53
  • @GregTarsa: Hmmm... that's odd. I can't think of any reason you'd authenticate differently in cron. But I'm glad you cleared the hurdle. Let us know if anything else comes up. – Seamus Feb 20 '20 at 3:46

You must log in to answer this question.

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