FMS Linux on CentOS 7.9 and 8.2

I downloaded a fresh copy of CentOS 7 today and got version 7.9.

I created a new VM here.
fms_19.1.2.234 installs fine for me.
No dependencies issues here.

Firefox on that server worked for me to pick standard FileMaker SSL Certificate.

For CentOS 8.2 we got the following errors reported for unfulfilled dependencies:

Problem: conflicting requests

  • nothing provides mysql-connector-odbc needed by filemaker_server-19.1.2-234.x86_64
  • nothing provides t1lib needed by filemaker_server-19.1.2-234.x86_64
  • nothing provides baekmuk-ttf-batang-fonts needed by filemaker_server-19.1.2-234.x86_64
  • nothing provides ipa-pgothic-fonts needed by filemaker_server-19.1.2-234.x86_64
  • nothing provides wqy-zenhei-fonts needed by filemaker_server-19.1.2-234.x86_64
  • nothing provides ImageMagick >= needed by filemaker_server-19.1.2-234.x86_64
    (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

So 7.9 is fine, but 8.2 is not working. Get version 7 ISO here: CentOS Mirrors List


Does anyone know how the CentOS FMS version would work on a production CentOS server with 6 GB RAM?


That's an odd question; why would you think it wouldn't work?
Feels like there is another more subtle possible constraint at the source of this.
Mainly also because 6GB is a weird number for RAM. It's usually 2-4-8-16-32...

I'm asking since FMS usually expects the server all to itself and I want to make sure that installing it wouldn't unduly burden my server (eat too much RAM) or otherwise negatively impact it.

If nobody has tried installing FMS on a production Linux CentOS 7.9 server, then I won't either. Server has Web sites, email, etc.

Nothing subtle. Just need to keep production stuff humming along...

The 6 GB was just a free RAM upgrade offered to me. It works fine.


FileMaker can't run well with a web server on the same machine as both need port 443 (and 80).

For that FileMaker uses apache on Linux if I remember correctly, but as they define a config for it using those ports, you get trouble if there is one using same ports.



The reason to dedicate a machine to FMS is two-fold:

  • performance - but that depends highly on available resources and the design/nature of the solution. In general you want to avoid anything that uses a lot of computing cycles or a lot of disk i/o. In that sense a busy web site or busy email server are poor co-tenants.
  • uptime / business continuity: this is by far the most important reason - by combining roles you may be incurring more downtime than is necessary - say if you have to patch the email server and force your FM users to disconnect. Or if hardware fails and you lose multiple crucial tools in one fell swoop.
    Add to that any config change that admins make for any of the other roles that may adversely affect FMS (stability and security). We see this all the time and the cost incurred with fixing it pays for a dedicated sever over and over.

As to memory: depends on how much server-side activity you generate but do keep in mind that the amount of db cache you set in the FMS prefs is grabbed from RAM by FMS and NOT shared. So by setting this high you may be starving the other processes from the resources they need. Or vice versa. It's usually not worth the hassle trying to spin all those plates in the air.

1 Like

Chiming in here...

I tried installing FMS19 on a host of unix flavors (CentOS 8, Fedora, Ubuntu) - all of them fail with similar errors - nothing provides followed by a list of different packages.

In some cases, like CentOS 8, I was able to install all of the missing packages except the Korean (batang) fonts. For some reason, CentOS 8 did not like those at all. I tried several different ways to install them and it failed every time.

1 Like

Thanks for that reply. :slight_smile:

I really don't see what CentOS brings other than another potential hosting OS (or a free VM to install locally for testing?). For my hosting clients, AWS/Windows seems the best option.


Many IT departments don't want to spend a Windows license on a server if they don't have to, and they are very familiar with CentOS - so that makes for much easier inroads here. More love from those IT folks.

Plus it makes FMS deployments cheaper; which is always good.
And CentOS - by nature - favors resilience and stability by being slow to adopt new anything in its kernel and packages. It is very much the enterprise OS that RHEL is. Heck 'enterprise OS' is even in its name.

Easier to package into Docker or similar containers to...

The list goes on...

For me AWS/Centos is the combination to beat. It can be beat on the features that that flavor of FMS doesn't have that the other on-prem versions do have (traditional EA, XML and PHP APIs...)


better stay with CentOS 7.x.

Claris may do a future version of FMS with CentOS 8 packages.

1 Like

Thanks. I have lots of experience with CentOS. The main FMI forum has plenty of problems posted using the Linux FMS distro, but these will get ironed out I'm sure.

I also use Docker quite a bit so thanks for that bit too.

This is slightly off-topic, and directed to the folks at Monkeybread Software:

Does the Linux MBS plug-in work with FileMaker Server 19 on CentOS 7.x?

And is using a script in FileMaker the best way to install it on the Server?

Yes, of course the plugin works.

You can install manually or via Install Plugin Script Step.

So, I know where the plug-in goes:

/opt/FileMaker/FileMaker Server/Database Server/Extensions

The next question is how to get it there.

I know there are several manual methods, but since this is Unix and we have some wonderful command line tools, can I use something like wget to download it directly to that directory?

Just use the Install plugin script step and call it in a PSoS script, or a schedule

You can of course download it with curl/wget or whatever you prefer and use cp to copy it there.
Make sure it's readable for the FileMaker process.

or just install by script, like this one: MBS FileMaker Plugin Update Check Script

Thanks Christian
Cheers, Nick