Provide a Remote File System for the FME Flow System Share

• Skill Level: Intermediate
• Estimated Time Required: 5-15 minutes
• Prerequisites:
  • Domain Service Account has correct permissions on network shares.

FME Flow System Share files, which include Repositories and Resources, are installed in specific directories that are shared to enable access from different computers.

Create a directory for the FME Flow System Share that is physically separate from the machine on which the FME Flow Core and web application server are installed. Separating the file system ensures it remains available in a fault tolerant scenario.

When providing a remote file system, keep in mind the following:

• The accounts that run the FME Flow components must have read and write permissions on the remote file system directory. For more information, see Directory and Account Permissions.
• In addition to being physically separate, the file system should, by itself, be configured for fault tolerance.
• When the directory is specified during installation, it must be in the form of a UNC path. Mapped drives are not supported.
• The directory that holds the System Share must be empty, unless System Share folders have already been created there as part of an installation involving multiple FME Flow Cores.

For information about acquiring a fault tolerant file system, consult your IT department.

Linux Only

For distributed installations on Linux, it is necessary, prior to installation, to create a group fmeflow represented by the same group identifier (GID) across each machine hosting the FME Flow Core, FME Web Services, and FME Engines, along with a user fmeflow on these machines.

Instructions

Perform the following steps on each machine hosting the FME Flow Core, FME Web Services, and FME Engines:

1. Create group fmeflow represented by the same GID:

groupadd -g <shared-gid> fmeflow

Where <shared-gid> is the same (identical) GID to represent group fmeflow across all machines.

2. Create user fmeflow:

useradd -m -g fmeflow fmeflow

3. If your file sharing protocol is Common Internet File System (CIFS), mount the FME Flow System Share directory so that group fmeflow has read and write permissions, and FME Flow components can set file permissions on the share. For example:

mount -t cifs //network/share /mnt/data \

-o uid=fmeflow,gid=fmeflow,file_mode=0664,dir_mode=02775,noperm

Why the noperm option is required

FME Flow runs its components under several service accounts, including fmeflow, fmeflowengine, fmeflowweb, and fmeflowdb. However, a CIFS mount can present files on the share as belonging to only one account — the one specified by the uid= option.

Granting the fmeflow group read and write access to the share is not sufficient. Certain operations, including changing a file's permissions, ownership, or timestamps, require the calling process to be the owner of the file. Membership in the file's group does not satisfy this requirement. Any FME Flow component whose service account does not match the uid= option therefore receives an "Operation not permitted" error when it attempts one of these operations, even though it can create, read, and write files normally.

Restricting access when using noperm

Because noperm disables permission checking on the FME Flow host, any local user on that host can read and write on the System Share, limited only by the permissions of the account used to mount it. On a dedicated FME Flow host this is usually acceptable, because the only accounts present are the FME Flow service accounts and administrators.

If other users have access to the host, mount the share beneath a directory that only the fmeflow group can enter. For example:

mkdir -p /opt/fmeflow-mnt/data

chown root:fmeflow /opt/fmeflow-mnt

chmod 0750 /opt/fmeflow-mnt

mount -t cifs //network/share /opt/fmeflow-mnt/data \

-o uid=fmeflow,gid=fmeflow,file_mode=0664,dir_mode=02775,noperm

Reaching a file inside the share still requires permission to traverse each parent directory. Those checks are performed against the local file system and are not affected by noperm, so a user who is not a member of the fmeflow group is refused access to /opt/fmeflow-mnt.

On a Network File System (NFS), the FME Flow installer must run as root and be able to assign ownership of directories on the System Share to the FME Flow service accounts. If root_squash is enabled (as by default on a self-managed NFS server), temporarily enable no_root_squash on the exports file of your server for the duration of the installation.

Following installation, map squashed root to user fmeflow and group fmeflow with anonuid=<fmeflow-uid>,anongid=<fmeflow-gid>. This allows FME Flow to run normally once installed, because each component writes as its own account. It is not sufficient for installation, because the installer cannot change ownership of files it does not own.

Note  Managed NFS services on Cloud providers such as Amazon EFS, Google Filestore, and Azure Files (NFS) do not squash root by default.

See Also

• Directory and Account Permissions