What Jellyfin NFO Files Preserve When a Library Moves

A Jellyfin NFO file can carry a film’s description, identifiers and other supported metadata beside the video. It cannot stand in for a recoverable copy of the media server. For a homelab library move, treat portable descriptions, actual media files and server state as three separate things worth preserving.

This distinction matters most when a collection contains corrections that cannot simply be downloaded again: a carefully chosen title, a custom synopsis or a deliberate sort order. A new server finding the same video does not automatically mean it will reproduce every decision made on the old one.

The portable part is a description, not the server

An NFO sidecar is a local metadata file associated with a media item. Jellyfin’s NFO documentation describes both reading and writing supported fields. These include titles, plot information, provider identifiers and many other details, with different supported tags for different kinds of media.

That makes sidecars useful when the goal is to let another compatible library read curated descriptions. It does not make every field universal. The application receiving the files must understand the relevant names and values; sharing a file extension is not a guarantee that two media tools interpret everything identically.

Think of the preservation layers separately:

• Video and audio files supply the actual content.
• Sidecars and local artwork supply information about that content.
• The server’s data and configuration preserve the installation that serves it.

Copying only one layer leaves the others dependent on reconstruction or another backup.

A local sidecar can outweigh an online correction

Jellyfin documents that local NFO metadata takes priority over remote metadata providers, and that NFO fetching cannot currently be disabled. This gives a curated sidecar practical authority, but it also means a stale file can keep supplying an unwanted title or synopsis.

A mismatch therefore has two possible homes: the record shown by the server and the local information used to populate it. Repeatedly choosing a different online match without checking the adjacent sidecar can miss the underlying reason for an unexpected result.

There is also a narrower conflict inside a single file. Some different tags map to the same Jellyfin field; the documentation gives plot and review as an example and says the later matching tag takes priority. A sidecar assembled by several tools deserves inspection before it becomes the trusted description of a large collection.

File placement is part of the metadata contract

A sidecar is useful only if the receiving server associates it with the intended item. Jellyfin documents media-specific names, including tvshow.nfo for a series and an episode filename with the .nfo extension for an episode. Its movie organization guide recommends separate movie folders and shows sidecars and artwork beside the video.

This is not a reason to rename an entire archive before a move. It is a reason to preserve the relationship between the video, directory and companion files. A backup selection that includes only large video extensions can silently omit the small files containing the most time-consuming editorial work.

Artwork adds another dependency. NFO files can refer to local image paths or remote URLs. A path that worked on one home server may not exist on another, while a URL still depends on the remote resource. Jellyfin also documents that artwork specified in NFO files has precedence over remote image providers and media-folder images. A visible poster is therefore not proof that its image bytes are preserved locally.

Watch history is not a household export

Jellyfin supports NFO user-data tags such as watched, playcount and lastplayed, but its documentation explicitly limits user-data importing to one user selected in the NFO settings. That is a significant boundary for a household with separate profiles.

A collection of sidecars should not be described as a migration of everybody’s playback history, permissions or account configuration. Even when an individual watched flag transfers correctly, that result does not establish that the whole multi-user installation has been recovered. Keep expectations tied to the documented import behavior rather than the presence of familiar tag names.

Writing sidecars changes the storage decision

Reading an existing NFO file and writing a new one are different operations. Jellyfin offers an Nfo saver option in library settings for exporting supported metadata. The server needs write access to the destination for that export to succeed. A deliberately read-only media mount can still be a sensible playback arrangement; enabling an exporter is not a reason to grant broad write permission without deciding who owns the library’s metadata.

If a separate media-management tool already maintains sidecars, choose a clear owner rather than assuming every application should rewrite them. Compatibility includes the filesystem permissions and the tools editing the files, not merely the Jellyfin version. Before allowing library-wide changes, preserve the existing sidecars and evaluate a small, disposable copy of representative media.

Recovery needs its own evidence

Jellyfin’s backup and restore documentation distinguishes its built-in backup system from a manual copy of server data and configuration. The built-in feature was added in version 10.11; the manual method requires stopping the server first. Neither a successful metadata export nor a directory full of videos demonstrates that those server recovery requirements have been met.

For a move, define success before changing the original installation: the copied media opens, the intended descriptions and artwork appear, and any required user state is verified separately through the appropriate restore path. Keep the original server data and the prior sidecars intact until those checks are complete.

Version compatibility matters for rollback too. Jellyfin warns that database migrations prevent simply running an older version against upgraded data; returning to the older installation requires a suitable backup. NFO files can make a curated collection easier to describe again, but they are not an escape hatch from a failed server upgrade.