TerraMaster Forum

I've noticed what may be a bug, or at least unexpected behaviour, with the Emby package under TOS7.

System
NAS: F6-424
TOS version: latest TOS7 release
Emby package: official TerraMaster App Center version (4.9.0.70)
Storage pools:
Pool 1 = HDD RAID array (/Volume1)
Pool 2 = NVMe SSD pool (/Volume2)
App installation location in App Center is configured as Pool 2 (NVMe)
Expected behaviour

Because applications are configured to install to Pool 2, I expected both:

Emby application binaries
Emby data (database, metadata, posters, artwork, subtitles, cache, plugins)

to reside on the NVMe pool.

For example:

/Volume2/@apps/emby
/Volume2/Emby
Actual behaviour

The Emby application itself installs correctly onto Pool 2:

/Volume2/@apps/emby

However, Emby automatically creates its data directory on Pool 1 instead:

/Volume1/Emby

This contains:

config/
data/
metadata/
cache/
plugins/
logs/
transcoding-temp/

including:

library.db
artwork/posters
subtitle downloads
metadata
plugin data
user database
Emby Premiere licence file (mb.lic)

The helper command used by the package also resolves to Pool 1:

ter_share_add -name "Emby"

returns:

/Volume1/Emby

even though App Center is configured to install applications onto Pool 2.

Why this matters

The Emby database and metadata store are fairly I/O intensive and benefit from SSD storage.

Many users deliberately install applications onto an NVMe pool specifically so that:

databases
thumbnails
metadata
artwork
subtitle caches

remain on fast SSD storage rather than consuming capacity and I/O on the main HDD array.

Question

Is this intentional behaviour in TOS7?

Or should Emby data follow the selected application installation location and therefore be created under:

/Volume2/Emby

when Pool 2 has been selected as the application destination?

At the moment there appears to be a mismatch between:

Application binaries → Pool 2
Application data → Pool 1

which was a little unexpected.

Please note that Emby is not developed by TerraMaster — it's a third-party application. Where it stores its data is determined by the app itself. We'd suggest reaching out to the Emby team directly regarding this issue.

Thank you for the clarification. I appreciate that Emby is a third-party application. However, the TerraMaster package appears to determine the program data location via the ter_share_add -name "Emby" helper, which on my system returns /Volume1/Emby despite App Center being configured to install applications to Pool 2 (/Volume2). Since the Emby launcher passes this path to Emby as its -programdata argument, it seems that TOS is selecting the storage pool used for Emby data. Could you confirm whether this behaviour is intentional in TOS7?

In the App Center, you can change the app's installation location, not its data storage location; that location is determined by the application itself. In TOS, the default storage location is usually Volume 1.

digi999 wrote: ↑08 Jul 2026, 01:07

I suspect that there is more to "ter_share_add helper". It is not just a 'helper' it is a means of setting a shared folder. There are options for defining the device for example. I suspect the calling procedure would first need to establish the "correct" device and specify the same. Otherwise it just defaults to a known value. Much like defining the "user" which defaults to "root" - or in this case, possibly - the defined "root" super-admin user.

digi999 wrote: ↑08 Jul 2026, 01:07 Thank you for the clarification. I appreciate that Emby is a third-party application. However, the TerraMaster package appears to determine the program data location via the ter_share_add -name "Emby" helper, which on my system returns /Volume1/Emby despite App Center being configured to install applications to Pool 2 (/Volume2). Since the Emby launcher passes this path to Emby as its -programdata argument, it seems that TOS is selecting the storage pool used for Emby data. Could you confirm whether this behaviour is intentional in TOS7?

You're right. The ter_share_addinterface creates folders in /Volume1/by default. When an app creates a folder through this interface, it doesn't know how many volumes are present on your system, so the developer has no way to preselect a location — hence the default. You might want to check with the developer on how to change the directory path.

To specify the volume, use: ter_share_add -name <name> -device <device>

Thank you, that makes sense. I believe this explains the behaviour I observed. Since the Emby launcher currently calls ter_share_add -name "Emby" without specifying -device, the helper defaults to /Volume1. If App Center already knows the application is installed on Pool 2, would it be possible for the launcher or App Center to pass the appropriate -device parameter automatically? That would keep the application data on the same storage pool as the application itself and would better match user expectations.

Just as an add on as Plex has consistently worked through the upgrade

I've compared this with the official Plex package supplied through App Center.

Plex is also installed to Pool 2, however both its application binaries and application data are created on Pool 2:

/Volume2/@apps/plex
/Volume2/Plex

whereas Emby creates:

/Volume2/@apps/emby
/Volume1/Emby

This suggests the behaviour is inconsistent between the official App Center packages rather than being an inherent limitation of third-party applications.

digi999 wrote: ↑08 Jul 2026, 19:31

We appreciate your test feedback. The issue you reported has been communicated to the product team for assessment.

digi999 wrote: ↑08 Jul 2026, 19:31

We have tested and verified the issue you reported. Here are the results:
If you have never installed or used Emby before, when you install it on Volume 2 for the first time, the Emby shared folder will also be created on Volume 2.
If you previously installed and used Emby on Volume 1, the Emby data directory created on Volume 1 will not​ be automatically deleted when you uninstall Emby. You will need to delete that shared folder manually.