A new release of our free bBox FileMaker plug-in is now available.

Extend the reach of your Mac OS X-based FileMaker solutions to programs, code libraries, or OS functions that are normally outside your reach, including AppleScript, Shell scripts, Python and Ruby.

Got white space? Here is a FileMaker custom function that hides the portal scroll bar if there are no additional records to display. This is the first post in a series on building a different kind of FileMaker-based contact management solution that looks and behaves like the OS X Address Book.

One of the primary tools we have available to us when designing user interfaces is color. Adding some categorization to your data using a little color can make it much more approachable and usable. The technique presented here will give you (on Mac OS X) a polished and robust Color Picker with no other requirements than a custom function and a global field. You can even set the default colors displayed on the Color Picker.

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.