This may be the reason:
I have a VBscript on a windows server system that moves backup files from the directory where a scheduled back up put them to an external drive. It runs fine when I run the script directly but fails every time I tried to run it from a server schedule. When I posted the issue here, TSGal informed me that server scheduled system scripts can't access external drives.
In my case, the work around was to use Windows Task Scheduler to run the VBscript instead of Server. I'm thinking you may be able to use something like cron to do the same with your applescript.
You must have some script step which is not supported in server scheduling.
for example, I came across one that I used "Save Record As PDF" which I intended to get a A/R list PDF daily, but log shows "... script aborted".
Thank you both for your responses :) I had known that FMS was unable to access external disks. However, I had, naively perhaps, assumed that being an applescript file on the disk that is would be launched in an applescript process thread instead of an FMS thread. I am no expert in the ways of the mac world, but after digging around in the KB and the forums, I am brought to guess that it must launch as a child thread so that FMS can keep control of the process enough to suppress UI interactions & be able to kill the process at will (ie timeout). Still, with FMS11 asking under which system user signin you wish to run the schedule as, I would think it would have that signin's permissions/rights/abilities. I had read in the a forum (may have been TSGal I am roughly referencing but I do not have the reference up at the moment) that a reason for denying FMS ability to access any but a few directories outside of its own for read/write had to do with permissions. I thought perhaps it logically followed to be a similar situation with external disks. Hmm.. perhaps it is more of a security issue with external disks than it is a permissions issue? But once again, I would think that an applescript running in an applescript thread with the assigned permissions of the account FMS allows you to designate should be able to do as a person signed into that account could do with the same applescript file. Why would that not make sense? Any ideas?
Like I suggested earlier. Use an OS level scheduler such as Cron to run your applescript instead of a Filemaker server schedule. That worked for me in the windows world (using windows task scheduler) and I suspect it will work for you on the Mac side in similar fashion.
I can and might do that. I simply wanted to get some idea in my head of what was going on with FMS in this instance. Silly of me to want FM to make sense :D Thanks again
I didn't find anything on Google about this "aborted by user" error that helped. And then I found out something interesting.
I have this simple bash script:
It returns the "aborted by user" error, even when I login using my own credentials in the schedule options.
If I use this bash script:
touch /Library/FileMaker\ Server/Documents/RequestBackup
I can use the default credentials, because this folder is OK with fmserver credentials.
My conclusion is that this probably is a FileMaker Server bug, overriding the credentials with your own doesn't work. As I can get around it by using the Documents folder, I do not care reporting this to FileMaker. I've done my share of reporting, and I am a bit wary of doing all that reporting.
My attempts show that this isn't even a matter of credentials or permissions at all. I created an Applescript that simply tells the Finder to activate and even that simple script showed "Aborted by user". Then I tried to just "beep" and no go. I'd like to know just what kind of an Applescript FMS can even run.
If I'm not mistaking, you're not supposed to "user-interact" in your AppleScript. The 2 commands you are describing are user interactions.
Recently ran into a similar situation and managed to fix it.
Turned out to be a permissions issue. Even though I set up the schedule in FMP Server Admin to run as a user I knew could successfully run the script on the command line, and eventually as root (as a last ditch effort), it still did not work. But, once I correctly set the file permissions and set up the schedule to run with the default account, it worked. So it seems that specifying an account in the script schedule assistant does not work.
To come to this conclusion, I ran the script from the terminal as the fmserver user. Then, from the terminal, I was able to get the feedback I needed to fix the problem. So, if you can run the script from the command line as the fmserver user, it should then work in the FMP Server schedule. If you can't, then it won't.
Here's how to run the script in the Mac terminal as fmserver:
- Type "su root", hit enter and enter the root password. (Alternatively, if you do not know your root password, you can type "sudo bash", then enter your account password.)
- Type "su fmsadmin" and hit enter.
- Type the full path to your script and hit enter. (Hint: you can drag the script file into the terminal window and it will enter the path for you.)
FYI: In the past, I have used shell scripts that copy the contents of the backup folder to other folders, including external drives. There should be no problem with accessing external drives from scripts. FMP is just running the script. I can't imagine there's any way it could possibly have that level of control over external scripts without it being ridiculously over-engineered. The main thing is that the fmserver user (and/or the fmsadmin group) have permission to execute the script itself and do everything the script is supposed to do. If you can't run it from the command line as fmserver, you can't run it in a server schedule. So, check the permissions of the script in the "Get Info" window and any folders the script has to access.
This bug is surviving a major revision of FileMaker Server again.
I submitted it to FMI.
Got a an answer from somebody at FMI who is a better documentation reader then I am.
In the schedule assistant progress, the third item is
3. Select the script
This is the part in the assistent where you choose the script and enter the alternate user name.
Now hit the help button below left. If you are the server itself, the url to the help page is
Scroll down to the Notes section and there you have it.
Edit the sudoers file following the instructions there. I tried exactly that and immediately everything worked fine.