If you have a FileMaker system and you need to script the processing of adding or removing files on the server, the first problem you are going to come across is: how do I stop the server from a script?

You may already be familiar with the fmsadmin command. This is present on both Mac OS and Windows installs of FileMaker server. You can simply run the following command in Terminal to stop the server:

fmsadmin stop server

The difficulty is that this command normally expects a live user to key in some information to complete the command. In particular, a password must be supplied.

How do we stop the server from a script then?

fmsadmin -uYourAccount -pYourPassword -y -t300 stop server

Here we have supplied the user name and password, plus the -y option to answer that yes, we really want to stop the server, and -t to allow users up to 5 minutes to log off the database files.

Somewhat incongruously, to restart the server when done you simply use:

fmsadmin start server

No user or password is required.

Other Methods

On the Mac OS, if your script is running as root, you could’ve also used launchctl to stop the server:

launchctl stop com.filemaker.fms

The main downside to this is that you can’t specify a grace period to disconnect users. Also, if your script isn’t currently running as root, you’d have to use the sudo command to make command execute as root, and the expect command to supply a password to sudo.

For Windows, you do something similar to launchctl on OSX to stop the FileMaker database service:

net stop "FileMaker Server 8"

Kill Command

On OSX, you will almost never want to use the kill or killall command on the fmserverd process. If you do, the launchd daemon will almost immediately restart the server process. If for some you do need to use this command, perhaps because a server is not responding normally, perform in this order for best results:

sudo launchctl stop com.filemaker.fms
sudo killall fmserver_helperd
sudo killall fmserverd

Even more dangerous is to use kill -9, which is likely to cause any open files to be corrupted. If you must force quite the server, first disable or disconnect the network connection on the server, wait at least a minute, and only then force quite the fmserverd process. This should reduce the chances of your database being corrupted.

The Problem

Most FileMaker Server setups on OSX that I have seen are using the default permissions as set by the FMS installer. When viewed in the Terminal, they look like this:

drwxrwxr-x  11 fmserver  fmsadmin   374 Jul 16 12:54 Databases

These permissions say that the fmserver user and the fmsadmin group both have read, write, and execute permissions to the folder and it's contents. So far, so good. But who's getting those read and execute permissions? Why, EVERYONE does! Although there can easily be exceptions depending on a server's configuration, it's likely this means that any user with shell/SSH, SFTP, ARD (Apple Remote Desktop), or VNC access will have read access to all your live database files and their backups.

This issue also pops up if you copy a new database file into your database directory. An all too common mistake is to forget to set the file so that either the fmserver account or the fmsadmin group has write access to it. With the Upload feature now found in FMS 9 Admin console this is not as big a problem as it used to be, but there are still occasions where its desirable to copy a file directly to the database folder.

The Solution

So, how do we fix this? My solution is two-fold. First, for any account that should have direct access to the database files I fire up the Terminal and do the following:

sudo dscl . append /Groups/fmsadmin GroupMembership theaccountname

This will make the user's account a member of the fmsadmin group. Even if you do nothing else, this will give the user both read & write access the the database folders and their files.

Next, we need to modify the permissions to the folder containing the database files. The default location for this is:

/Library/FileMakerServer/Data/Databases

sudo chmod o-rx /Library/FileMakerServer/Data/Databases

We have now removed the ability of anyone who isn't fmserver or in the fmsadmin group to read the contents of the Databases folder. Next, and this is perhaps the trickiest part, we us an ACL based permission to allow the fmsadmin group full access to the Databases folder, overriding the previous POSIX style permissions. Additionally, it causes all enclosed files and subdirectories to also inherit the same permissions. The somewhat lengthy command looks like this:

sudo chmod -R +a 'fmsadmin allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readsecurity,directory_inherit,file_inherit' '/Library/FileMaker Server/Data/Databases'

If logged in as a user in the fmsadmin group you should now be able to copy over new files or create directories in your Databases folder and have them pick up the correct permissions for FMS to read and write to the file. If you want to check this, just be sure to use the -e option with the ls command, otherwise the ACL's won't be displayed.