Jump to content
Server Maintenance This Week. ×

System Script Aborted by User


Pbeyrouty

This topic is 2871 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I am having a problem running a shell script from Filemaker server 11 on a Mac running 10.6.8. Every time I try to run it the log says it was aborted by user. The script is designed to look in a folder for an XML file. If there is one it changes the format and replaces some characters so that it will import into Filemaker correctly. The script works fine when I run it from terminal but fails from FMS. At first I thought it might be because the folder it is checking isn't on the machine itself but on a shared drive. However, I tried the script when it was looking at a local folder and it had the same problem. I tried changing the permissions on the folders and having the script run using the admin account. I always get the same result. Also, other shell scripts run without a problem from the server... Has anyone had similar issues?

Link to comment
Share on other sites

Typically it means an error in the script... can you have it produce some output (write to a text file) on any errors? Are you specifying an OS user account when running the schedule? Pick an account that has sufficient rights to do what needs done. If you don't specify an account then it will run as user fmserver and that one may not have enough privileges.

Link to comment
Share on other sites

Yeah I tried it without a user specified and with the admin specified. When I run it manually it works fine and creates the file as need. I guess I will try having it write the results to a file as it goes.

Link to comment
Share on other sites

Unfortunately that is what I meant, I did both. I tried setting it in the schedule to run without an account specified and then I tried running it in the schedule with the account that I tested it with when running from terminal. Neither worked from the FMS even though it worked fine when I tried it manually with that user account. It's weird.

Link to comment
Share on other sites

  • 1 month later...

I am having the same problem with a simple script that copies the contents of the backup folder to a dropbox folder. I can run the script fine from the command line, but the script will not run from FMP 12 Server. I've even had FMP run the script as root.

I had used a similar script in the past in FMP 11 Server that copied the contents to an external drive. It worked fine.

Link to comment
Share on other sites

I fixed the problem. It was a permissions problem. It seems that specifying the user in the server scheduler does not work. Once I correctly set the file permissions and set up the schedule to run with the default account, it worked.

To come to this conclusion, I ran the script from the Mac 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 (possibly a similar method in Windows, but I don't know it):

  1. 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.)
  2. Type "su fmsadmin" and hit enter.
  3. 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/files the script has to access.

Link to comment
Share on other sites

  • 5 months later...

I realize this is an old thread, but I ran into the same problem and found the solution.

 

On OS X, in order to use a non-default account, you must modify the /etc/sudoers file. This is documented here: http://help.filemaker.com/app/answers/detail/a_id/7601/~/specifing-a-user-account-to-run-system-level-scripts-with-filemaker-server

 

It's kind of silly that this is so buried (it's not in the main FM Server documentation PDF, and it's also not mentioned in the error message), but once you make that change, everything works OK.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...
  • Newbies

I realize this is an old thread, but I ran into the same problem and found the solution.

 

On OS X, in order to use a non-default account, you must modify the /etc/sudoers file. This is documented here: http://help.filemaker.com/app/answers/detail/a_id/7601/~/specifing-a-user-account-to-run-system-level-scripts-with-filemaker-server

 

It's kind of silly that this is so buried (it's not in the main FM Server documentation PDF, and it's also not mentioned in the error message), but once you make that change, everything works OK.

I'm having a similar issue. I've followed the instructions in the linked article but I'm getting syntax errors or an unused host alias warning.

 

Jesse, would you mind posting what your sudoers file looks like please as I don't think the article is very clear on how the file needs to be modified.

Link to comment
Share on other sites

Here is the section that I added to my sudoers file. It's working OK for me now:

 

 

Host_Alias FMSHOST = apollo.local
Defaults:fmserver targetpw, timestamp_timeout=0, passwd_tries=1 
fmserver FMSHOST = (ALL) /Library/FileMaker Server/Data/Scripts/*, /bin/kill
  • Like 1
Link to comment
Share on other sites

  • Newbies

Thanks Jesse,

 

The problem was that the KB article has the 'bin/kill' on its own line rather than following on as a single line as in your post above. I added the following to my sudoers file and it caused syntax errors:

 

 

Host_Alias FMSHOST = Hostname
Defaults:fmserver targetpw, timestamp_timeout=0, passwd_tries=1 
fmserver FMSHOST = (ALL) /Library/FileMaker Server/Data/Scripts/*, /
bin/kill

 

Once I moved 'bin/kill' up onto the previous line, the sudoers file saved with no syntax errors. I've set the schedule to run with the root user account.

 

Thanks for your help.

Link to comment
Share on other sites

  • 3 years later...

Hi Jesse-

I am trying to make this work, too, but can't get the scripts to stop aborting.  I pasted this into the etc/sudoers file using sudo visudo:

Host_Alias FMSHOST = yourhostname
Defaults:fmserver targetpw, timestamp_timeout=0, passwd_tries=1
fmserver FMSHOST = (ALL) /Library/FileMaker\ Server/Data/Scripts/*, /bin/kill

and changed the hostname to the name returned by running the hostname command.

At what point in the sudoers file did you put this command?  I have tried it on the end and after the Alias HostName line.  Also, did you put your password where it says "taargetpw" or did you leave that there?

I have tried changing permissions on all of files I am accessing from the applescript I am running. I have tried using different passwords and usernames.  I have tried fmserver user name and password explicitly.

All for naught.  The script keeps saying user aborted. Do you have any other ideas, perhaps?

Thanks-  Don

 

 

 

Link to comment
Share on other sites

This topic is 2871 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.