About the Harmony Server Structure

The primary purpose of the database server is to host and manage the information on its Harmony scenes. Optionally, it can also host the actual scene data, but other machines on your network can be used for scene data storage as well, as those are two different components of a Harmony database.

A Harmony database is structured using different network shares:

  • The /USA_DB share, which contains the information on all the scenes, environments, jobs as well as shared assets such as palettes and templates stored in environments or jobs. This part of the database must be hosted on the machine that runs the database server service/daemon, to which client workstations will connect directly.
  • /usadata shares, which contain the actual scene data: the drawings, animation, 3D models, scene palettes, etc. Those can be hosted on the database server or on any machine on the local network that the client workstations can access. There can be as many as the studio needs, which allows you to expand the storage capacity of your database server by creating a new /usadata share on a new file server.

On client machines, every network share is mounted on the same location as the location of the actual share on their respective server. Likewise, if other servers are used to store scene data, the shares of these servers are mounted on the database server. The result is that the database file structure is entirely accessible on all machines in the network.

If you intend to use several /usadata shares, they must be numbered them. The best practice is to name the first /usadata share /usadata000, and it is typical, although not mandatory, to store that share on the same machine as the database server. Then, when you need to expand the storage space for your Harmony database, you can create a share named /usadata001 on another machine, and another one named /usadata002 on another machine, etc.

In the end, client machines will locate the different shares that compose your database by mounting those share points on the client machine's filesystem root.

On Windows machines, this is done by adding shortcut (.lnk) files in the root of a drive (typically C:) which point to the network path of the share, for example:

  • A USA_DB.lnk shortcut file pointing to \\dbserver\USA_DB.
  • A usadata000.lnk shortcut file pointing to \\dbserver\usadata000.
  • A usadata001.lnk shortcut file pointing to \\newfileserver\usadata001.

This process is automatically done by Configuration Wizard, a Windows-exclusive configuration tool for Harmony.

On macOS and GNU/Linux machines, this is done by mounting the shares on folders located at the root of the filesystem. By giving those folders the name of their respective shares, it simulates the presence of the server's files on the machine's filesystem. For example:

  • A directory named /USA_DB is mounted with the NFS share at address dbserver:/USA_DB.
  • A directory named /usadata000 is mounted with the NFS share at address dbserver:/usadata000.
  • A directory named /usadata001 is mounted with the NFS share at address newfileserver:/usadata001.

Typically, clients and servers can communicate without any issue if they use the same kind of operating system. It is possible to set-up a Harmony database that mixes different platforms across the database server, the file servers and the client workstations, but with some important limitations that must be taken in account:

  • By default, the use of non-alphanumerical Unicode characters, with the exception of the dash and the underscore, in Harmony for naming scenes, layers and drawings is not enabled, but can optionally be enabled. However, you must absolutely keep in mind that macOS and GNU/Linux typically fail to communicate filenames containing Unicode characters over the NFS protocol. This means that if Unicode is enabled on your database, and that a macOS based client tries to open or save a scene containing Unicode characters which is hosted on a GNU/Linux-based file server, Harmony will fail to open and save files with Unicode characters in their name, and there might be data loss! Hence, it is important to never enable Unicode if your network includesmacOS-based clients and GNU/Linux-based database servers or file servers, including GNU/Linux-based NAS servers.
  • If you set up your database server on a Windows machine, only Windows clients are supported. It may be possible to connect a macOS-based or GNU/Linux-based client workstation to a Windows-based database server, but this may cause unexpected issues and it is not a supported usage scenario.
  • If you intend to set up your database server on a macOS machine and you want Windows workstations to be able to connect to it, you will need to install a third party software, SMBup, and configure it to share your database files through the Samba protocol. This is because macOS natively supports the NFS sharing protocol, but not SMB, and Windows natively supports the SMB file sharing protocol, but not NFS.

To summarize, here is a table outlining the implications of mixing platforms between servers and clients:

↓ Client
Server →
Windows macOS GNU/Linux
Windows No problem. Requires SMBup to be installed and configured on the server. No problem.
macOS Not supported. No problem. Unicode must be disabled.
GNU/Linux Not supported. Unicode must be disabled. No problem.