Importing database connections in FME on Linux, no gui

Hello, @redgeographics.
Thanks for your question. Currently, we don’t have the ability* on the command line to import connections into an existing FME Environment.
*There is some support for this behavior via FME Packages (you can install a package on the command line). If that package has a web service, it will be imported into an existing FME Environment.
Also, APPLY_SETTINGS can only point your FME Environment to an existing connection database (if that is your intention).
My recommendation would be to create an Idea via +Start a post. It will prompt to see if others on the community are interested/have a need as well in supporting importing database connections (or other connections) via the Linux command line. Hope this helps!

But packages can only be created by Safe currently, correct?

Hey, @redgeographics.

They are open to all users who have the skills to do so. Guide: FME Packages SDK Guide.

Aha. I was looking in the general FME Packages FAQ (so yeah, maybe that page should be updated?)

27 years of experience working with FME, but apparently I don’t have the skills… 😐

I can’t find any reference to database connections in that guide. Am I overlooking something?

Hi, @redgeographics.

I double-checked the documentation as well and let the team know that its not there. Thanks for pointing it out!

Oh, good point seems like a bit of a hole in the process. 

Have you thought about just embedding connection parameters and using environment variables on the Linux system? I've done this in the past which has worked well, however, the password type parameter in FME doesn't pick up environment variables, so instead is used a scripted parameter. 

For me I needed a way to use an external database tool and couldn't use a database connection in FME. This was the way I was able to do it without the password showing up in the logs. 

It’s multiple (20+ if I recall correctly) workspaces using this connection, so that would be a bit of a hassle.

It’s multiple (20+ if I recall correctly) workspaces using this connection, so that would be a bit of a hassle.

Oh dang, yeah indeed a hassle and anyway not ideal at all, just a hacky workaround.

I'd like to know if there is a solution to do this on linux with FME Form 2026.2. I'm the customer ​@redgeographics is talking about. At that time we decided to stay on an older version of FME where it was possible to use the existing database connections. But since it is 2026 by now, we really have to update to a newer version.

I saw some documentation with the changes around database connections since 2024, but this documentation is all about Windows solutions.

Hi ​@koenterralytics, thanks for raising that! The Connection Storage changes article focuses on Windows-specific paths, so I'm looking into updating that.

It might be best to open a Support Case with us, actually. That way we can dig into your current setup and give you more targeted guidance. When you raise that, it'd help to share:

• Whether you're now running FME Form with a GUI available, and if so, any specific error messages you're seeing
• What connection storage you're using (or planning to use) on 2026.2: personal storage, shared connection, or FME Flow, along with your specific build of FME

In the future, it would be great to start a new community post, with older ones like this linked as references. That way it gets more visibility from other community users. Older threads like these tend to get lost.

And if you're still on the CLI-only setup, there's an open IDEA for exactly that. I'm sharing it here in case anyone else from the community would find a no-GUI import path useful and might want to upvote it:

[Internal ref: EXPERTS-14183]

In the end we were able to solve this with help of Safe technical support. What we had to do:

1. Change the connections from ‘personal’ to ‘shared’ following this description 
2. Change the relevant connections to shared
3. Copy the new connection file fme_userconnection.data and fme_sharedKey.fmekey to the correct folder on Linux (eg /home/<userName>/.Safe Software/FME")

After that we followed the next steps on Linux. This is a copy/paste from the email I got from support.

`/opt/fme-form-2026.2/fme APPLY_SETTINGS Security/FME_SECURITY_CONNECTION_STORAGE_SHARED_DATABASE_DEFAULT_CONNECTION_VISIBILITY SHARED`

`/opt/fme-form-2026.2/fme APPLY_SETTINGS Security/FME_SECURITY_CONNECTION_STORAGE_SHARED_DATABASE_FOLDER_PATH "/home/<userName>/.Safe Software/FME"`

`/opt/fme-form-2026.2/fme APPLY_SETTINGS Security/FME_SECURITY_CONNECTION_STORAGE_SHARED_KEY_FOLDER_PASSWORD ""`

`/opt/fme-form-2026.2/fme APPLY_SETTINGS Security/FME_SECURITY_CONNECTION_STORAGE_SHARED_KEY_FOLDER_PATH "/home/<userName>/.Safe Software/FME"`
 
The bolded parts are parts of the command you may need to modify, as these commands assumes Form 2026.2 is installed at `/opt/`, and the shared connection storage along with the shared key is placed in the default location: `/home/<userName>/.Safe Software/FME`, and the shared key does not have a password set. If any of these are not true, please modify the bolded text for your environment. Let me know if you run into issues or have questions on modifying the commands for your environment.
 
These tell FME that which Shared connection storage is used and to use the .fmekey file to decrypt instead of the personal key that is managed by Linux in the operating system keyring.
 
In addition, it might be good to remove the previous connection storage files such as `fme_connections.data`, `fme_privateKey.fmeks`, `fme_privateKey.jceks`, `fme_publicKey.fmeks`, `fme_publicKey.jceks` so only `fme_userconnection.data` and `fme_sharedKey.fmekey` to avoid confusion. If you do not wish to delete them, move them out of `/home/<userName>/.Safe Software/FME` as they are not used by FME 2026.
 
Moving them out might help with resolving this error:

    Migrating connection storage from version '4' to '5'

 
I will also mention that by using shared connection storage, the username on the Windows and Linux machines do not need to match anymore.