starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-07-16 05:43:54 +03:00
Code Issues 822 Packages Projects Releases 17 Wiki Activity

Jellyfin fails to start if /var/log/jellyfin has <512 MB free (DietPi / tmpfs log partition) #7614

New Issue
Closed
opened 2026-02-07 05:14:47 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-07 05:14:47 +03:00
Owner
Copy Link

Originally created by @deejaysyky on GitHub (Oct 28, 2025).

Description of the bug

System Information

  • Jellyfin version: 10.11.1 (installed from repo.jellyfin.org)
  • OS: DietPi (Debian 12 Bookworm)
  • Architecture: x86_64
  • .NET Runtime: 8.0
  • Systemd: 252.25 (Debian stable)
  • Install method: apt (official Jellyfin repository)

🧩 Description

Jellyfin fails to start on systems where /var/log is mounted as tmpfs (for example, DietPi, Raspbian, or OpenMediaVault).
The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere.

The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory /var/log/jellyfin.

As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning.

💥 Error log

System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space.
Available: 49.9 MiB, Required: 512 MiB.
at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...)
at Jellyfin.Server.Program.StartApp(StartupOptions options)
at Jellyfin.Server.Program.

(String[] args)

============================================================================
Systemd:

jellyfin.service: Main process exited, code=killed, status=6/ABRT

⚙️ Steps to reproduce

  1. Install Jellyfin 10.11.1 on DietPi (Debian 12 Bookworm)
  2. /var/log is mounted as tmpfs (e.g., 50 MB)
  3. Start Jellyfin: 
    systemctl start jellyfin

 Observe the crash:

 code=killed, signal=ABRT

 Check logs – insufficient free space error despite system having gigabytes free

✅ Expected behavior

Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space.

It should:

    Log a warning instead of terminating.

    Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag).

    Or skip log directory space checks for tmpfs mounts.

🔧 Workaround

Creating a persistent log directory and overriding via systemd fixes the issue:

mkdir -p /mnt/dietpi_userdata/jellyfin-logs
chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs
systemctl edit jellyfin

Add:

[Service]
Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs"

Then reload:

systemctl daemon-reexec
systemctl daemon-reload
systemctl restart jellyfin

After that, Jellyfin runs normally.
🧠 Additional context

This affects many lightweight or NAS-oriented distros that keep /var/log in memory.

The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64).

It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check.

🧾 Suggested Fix

In StorageHelper.TestCommonPathsForStorageCapacity():

Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC),
or reduce the required threshold for /var/log/jellyfin.

Reproducible: ✅ Always
Severity: 💥 High (prevents startup on many embedded systems)
Proposed labels: bug, linux, storage, debian, dietpi

Reproduction steps

System Information

  • Jellyfin version: 10.11.1 (installed from repo.jellyfin.org)
  • OS: DietPi (Debian 12 Bookworm)
  • Architecture: x86_64
  • .NET Runtime: 8.0
  • Systemd: 252.25 (Debian stable)
  • Install method: apt (official Jellyfin repository)

🧩 Description

Jellyfin fails to start on systems where /var/log is mounted as tmpfs (for example, DietPi, Raspbian, or OpenMediaVault).
The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere.

The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory /var/log/jellyfin.

As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning.

💥 Error log

System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space.
Available: 49.9 MiB, Required: 512 MiB.
at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...)
at Jellyfin.Server.Program.StartApp(StartupOptions options)
at Jellyfin.Server.Program.

(String[] args)

============================================================================
Systemd:

jellyfin.service: Main process exited, code=killed, status=6/ABRT

⚙️ Steps to reproduce

  1. Install Jellyfin 10.11.1 on DietPi (Debian 12 Bookworm)
  2. /var/log is mounted as tmpfs (e.g., 50 MB)
  3. Start Jellyfin: 
    systemctl start jellyfin

 Observe the crash:

 code=killed, signal=ABRT

 Check logs – insufficient free space error despite system having gigabytes free

✅ Expected behavior

Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space.

It should:

    Log a warning instead of terminating.

    Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag).

    Or skip log directory space checks for tmpfs mounts.

🔧 Workaround

Creating a persistent log directory and overriding via systemd fixes the issue:

mkdir -p /mnt/dietpi_userdata/jellyfin-logs
chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs
systemctl edit jellyfin

Add:

[Service]
Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs"

Then reload:

systemctl daemon-reexec
systemctl daemon-reload
systemctl restart jellyfin

After that, Jellyfin runs normally.
🧠 Additional context

This affects many lightweight or NAS-oriented distros that keep /var/log in memory.

The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64).

It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check.

🧾 Suggested Fix

In StorageHelper.TestCommonPathsForStorageCapacity():

Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC),
or reduce the required threshold for /var/log/jellyfin.

Reproducible: ✅ Always
Severity: 💥 High (prevents startup on many embedded systems)
Proposed labels: bug, linux, storage, debian, dietpi

What is the current bug behavior?

System Information

  • Jellyfin version: 10.11.1 (installed from repo.jellyfin.org)
  • OS: DietPi (Debian 12 Bookworm)
  • Architecture: x86_64
  • .NET Runtime: 8.0
  • Systemd: 252.25 (Debian stable)
  • Install method: apt (official Jellyfin repository)

🧩 Description

Jellyfin fails to start on systems where /var/log is mounted as tmpfs (for example, DietPi, Raspbian, or OpenMediaVault).
The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere.

The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory /var/log/jellyfin.

As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning.

💥 Error log

System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space.
Available: 49.9 MiB, Required: 512 MiB.
at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...)
at Jellyfin.Server.Program.StartApp(StartupOptions options)
at Jellyfin.Server.Program.

(String[] args)

============================================================================
Systemd:

jellyfin.service: Main process exited, code=killed, status=6/ABRT

⚙️ Steps to reproduce

  1. Install Jellyfin 10.11.1 on DietPi (Debian 12 Bookworm)
  2. /var/log is mounted as tmpfs (e.g., 50 MB)
  3. Start Jellyfin: 
    systemctl start jellyfin

 Observe the crash:

 code=killed, signal=ABRT

 Check logs – insufficient free space error despite system having gigabytes free

✅ Expected behavior

Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space.

It should:

    Log a warning instead of terminating.

    Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag).

    Or skip log directory space checks for tmpfs mounts.

🔧 Workaround

Creating a persistent log directory and overriding via systemd fixes the issue:

mkdir -p /mnt/dietpi_userdata/jellyfin-logs
chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs
systemctl edit jellyfin

Add:

[Service]
Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs"

Then reload:

systemctl daemon-reexec
systemctl daemon-reload
systemctl restart jellyfin

After that, Jellyfin runs normally.
🧠 Additional context

This affects many lightweight or NAS-oriented distros that keep /var/log in memory.

The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64).

It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check.

🧾 Suggested Fix

In StorageHelper.TestCommonPathsForStorageCapacity():

Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC),
or reduce the required threshold for /var/log/jellyfin.

Reproducible: ✅ Always
Severity: 💥 High (prevents startup on many embedded systems)
Proposed labels: bug, linux, storage, debian, dietpi

What is the expected correct behavior?

System Information

  • Jellyfin version: 10.11.1 (installed from repo.jellyfin.org)
  • OS: DietPi (Debian 12 Bookworm)
  • Architecture: x86_64
  • .NET Runtime: 8.0
  • Systemd: 252.25 (Debian stable)
  • Install method: apt (official Jellyfin repository)

🧩 Description

Jellyfin fails to start on systems where /var/log is mounted as tmpfs (for example, DietPi, Raspbian, or OpenMediaVault).
The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere.

The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory /var/log/jellyfin.

As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning.

💥 Error log

System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space.
Available: 49.9 MiB, Required: 512 MiB.
at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...)
at Jellyfin.Server.Program.StartApp(StartupOptions options)
at Jellyfin.Server.Program.

(String[] args)

============================================================================
Systemd:

jellyfin.service: Main process exited, code=killed, status=6/ABRT

⚙️ Steps to reproduce

  1. Install Jellyfin 10.11.1 on DietPi (Debian 12 Bookworm)
  2. /var/log is mounted as tmpfs (e.g., 50 MB)
  3. Start Jellyfin: 
    systemctl start jellyfin

 Observe the crash:

 code=killed, signal=ABRT

 Check logs – insufficient free space error despite system having gigabytes free

✅ Expected behavior

Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space.

It should:

    Log a warning instead of terminating.

    Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag).

    Or skip log directory space checks for tmpfs mounts.

🔧 Workaround

Creating a persistent log directory and overriding via systemd fixes the issue:

mkdir -p /mnt/dietpi_userdata/jellyfin-logs
chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs
systemctl edit jellyfin

Add:

[Service]
Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs"

Then reload:

systemctl daemon-reexec
systemctl daemon-reload
systemctl restart jellyfin

After that, Jellyfin runs normally.
🧠 Additional context

This affects many lightweight or NAS-oriented distros that keep /var/log in memory.

The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64).

It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check.

🧾 Suggested Fix

In StorageHelper.TestCommonPathsForStorageCapacity():

Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC),
or reduce the required threshold for /var/log/jellyfin.

Reproducible: ✅ Always
Severity: 💥 High (prevents startup on many embedded systems)
Proposed labels: bug, linux, storage, debian, dietpi

Jellyfin Server version

10.10.0+

Specify commit id

No response

Specify unstable release number

No response

Specify version number

10.11.1

Specify the build version

10.11.1

Environment

- OS:
- Linux Kernel:
- Virtualization:
- Clients:
- Browser:
- FFmpeg Version:
- Playback Method:
- Hardware Acceleration:
- GPU Model:
- Plugins:
- Reverse Proxy:
- Base URL:
- Networking:
- Jellyfin Data Storage:
- Media Storage:
- External Integrations:

Jellyfin logs

### System Information
- **Jellyfin version:** 10.11.1 (installed from repo.jellyfin.org)
- **OS:** DietPi (Debian 12 Bookworm)
- **Architecture:** x86_64
- **.NET Runtime:** 8.0
- **Systemd:** 252.25 (Debian stable)
- **Install method:** apt (official Jellyfin repository)

---

### 🧩 Description
Jellyfin fails to start on systems where `/var/log` is mounted as **tmpfs** (for example, DietPi, Raspbian, or OpenMediaVault).  
The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere.

The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory `/var/log/jellyfin`.

As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning.

---

### 💥 Error log

System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space.
Available: 49.9 MiB, Required: 512 MiB.
at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...)
at Jellyfin.Server.Program.StartApp(StartupOptions options)
at Jellyfin.Server.Program.<Main>(String[] args)

============================================================================
Systemd:

jellyfin.service: Main process exited, code=killed, status=6/ABRT


---

### ⚙️ Steps to reproduce
1. Install Jellyfin 10.11.1 on **DietPi** (Debian 12 Bookworm)
2. `/var/log` is mounted as `tmpfs` (e.g., 50 MB)
3. Start Jellyfin:
   
   systemctl start jellyfin

    Observe the crash:

    code=killed, signal=ABRT

    Check logs – insufficient free space error despite system having gigabytes free

✅ Expected behavior

    Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space.

    It should:

        Log a warning instead of terminating.

        Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag).

        Or skip log directory space checks for tmpfs mounts.

🔧 Workaround

Creating a persistent log directory and overriding via systemd fixes the issue:

mkdir -p /mnt/dietpi_userdata/jellyfin-logs
chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs
systemctl edit jellyfin

Add:

[Service]
Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs"

Then reload:

systemctl daemon-reexec
systemctl daemon-reload
systemctl restart jellyfin

After that, Jellyfin runs normally.
🧠 Additional context

    This affects many lightweight or NAS-oriented distros that keep /var/log in memory.

    The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64).

    It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check.

🧾 Suggested Fix

In StorageHelper.TestCommonPathsForStorageCapacity():

    Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC),
    or reduce the required threshold for /var/log/jellyfin.

Reproducible: ✅ Always
Severity: 💥 High (prevents startup on many embedded systems)
Proposed labels: bug, linux, storage, debian, dietpi

FFmpeg logs

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

No response

Originally created by @deejaysyky on GitHub (Oct 28, 2025). ### Description of the bug ### System Information - **Jellyfin version:** 10.11.1 (installed from repo.jellyfin.org) - **OS:** DietPi (Debian 12 Bookworm) - **Architecture:** x86_64 - **.NET Runtime:** 8.0 - **Systemd:** 252.25 (Debian stable) - **Install method:** apt (official Jellyfin repository) --- ### 🧩 Description Jellyfin fails to start on systems where `/var/log` is mounted as **tmpfs** (for example, DietPi, Raspbian, or OpenMediaVault). The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere. The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory `/var/log/jellyfin`. As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning. --- ### 💥 Error log System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space. Available: 49.9 MiB, Required: 512 MiB. at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...) at Jellyfin.Server.Program.StartApp(StartupOptions options) at Jellyfin.Server.Program.<Main>(String[] args) ============================================================================ Systemd: jellyfin.service: Main process exited, code=killed, status=6/ABRT --- ### ⚙️ Steps to reproduce 1. Install Jellyfin 10.11.1 on **DietPi** (Debian 12 Bookworm) 2. `/var/log` is mounted as `tmpfs` (e.g., 50 MB) 3. Start Jellyfin: ```bash systemctl start jellyfin Observe the crash: code=killed, signal=ABRT Check logs – insufficient free space error despite system having gigabytes free ✅ Expected behavior Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space. It should: Log a warning instead of terminating. Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag). Or skip log directory space checks for tmpfs mounts. 🔧 Workaround Creating a persistent log directory and overriding via systemd fixes the issue: mkdir -p /mnt/dietpi_userdata/jellyfin-logs chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs systemctl edit jellyfin Add: [Service] Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs" Then reload: systemctl daemon-reexec systemctl daemon-reload systemctl restart jellyfin After that, Jellyfin runs normally. 🧠 Additional context This affects many lightweight or NAS-oriented distros that keep /var/log in memory. The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64). It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check. 🧾 Suggested Fix In StorageHelper.TestCommonPathsForStorageCapacity(): Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC), or reduce the required threshold for /var/log/jellyfin. Reproducible: ✅ Always Severity: 💥 High (prevents startup on many embedded systems) Proposed labels: bug, linux, storage, debian, dietpi ### Reproduction steps ### System Information - **Jellyfin version:** 10.11.1 (installed from repo.jellyfin.org) - **OS:** DietPi (Debian 12 Bookworm) - **Architecture:** x86_64 - **.NET Runtime:** 8.0 - **Systemd:** 252.25 (Debian stable) - **Install method:** apt (official Jellyfin repository) --- ### 🧩 Description Jellyfin fails to start on systems where `/var/log` is mounted as **tmpfs** (for example, DietPi, Raspbian, or OpenMediaVault). The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere. The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory `/var/log/jellyfin`. As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning. --- ### 💥 Error log System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space. Available: 49.9 MiB, Required: 512 MiB. at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...) at Jellyfin.Server.Program.StartApp(StartupOptions options) at Jellyfin.Server.Program.<Main>(String[] args) ============================================================================ Systemd: jellyfin.service: Main process exited, code=killed, status=6/ABRT --- ### ⚙️ Steps to reproduce 1. Install Jellyfin 10.11.1 on **DietPi** (Debian 12 Bookworm) 2. `/var/log` is mounted as `tmpfs` (e.g., 50 MB) 3. Start Jellyfin: ```bash systemctl start jellyfin Observe the crash: code=killed, signal=ABRT Check logs – insufficient free space error despite system having gigabytes free ✅ Expected behavior Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space. It should: Log a warning instead of terminating. Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag). Or skip log directory space checks for tmpfs mounts. 🔧 Workaround Creating a persistent log directory and overriding via systemd fixes the issue: mkdir -p /mnt/dietpi_userdata/jellyfin-logs chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs systemctl edit jellyfin Add: [Service] Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs" Then reload: systemctl daemon-reexec systemctl daemon-reload systemctl restart jellyfin After that, Jellyfin runs normally. 🧠 Additional context This affects many lightweight or NAS-oriented distros that keep /var/log in memory. The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64). It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check. 🧾 Suggested Fix In StorageHelper.TestCommonPathsForStorageCapacity(): Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC), or reduce the required threshold for /var/log/jellyfin. Reproducible: ✅ Always Severity: 💥 High (prevents startup on many embedded systems) Proposed labels: bug, linux, storage, debian, dietpi ### What is the current _bug_ behavior? ### System Information - **Jellyfin version:** 10.11.1 (installed from repo.jellyfin.org) - **OS:** DietPi (Debian 12 Bookworm) - **Architecture:** x86_64 - **.NET Runtime:** 8.0 - **Systemd:** 252.25 (Debian stable) - **Install method:** apt (official Jellyfin repository) --- ### 🧩 Description Jellyfin fails to start on systems where `/var/log` is mounted as **tmpfs** (for example, DietPi, Raspbian, or OpenMediaVault). The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere. The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory `/var/log/jellyfin`. As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning. --- ### 💥 Error log System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space. Available: 49.9 MiB, Required: 512 MiB. at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...) at Jellyfin.Server.Program.StartApp(StartupOptions options) at Jellyfin.Server.Program.<Main>(String[] args) ============================================================================ Systemd: jellyfin.service: Main process exited, code=killed, status=6/ABRT --- ### ⚙️ Steps to reproduce 1. Install Jellyfin 10.11.1 on **DietPi** (Debian 12 Bookworm) 2. `/var/log` is mounted as `tmpfs` (e.g., 50 MB) 3. Start Jellyfin: ```bash systemctl start jellyfin Observe the crash: code=killed, signal=ABRT Check logs – insufficient free space error despite system having gigabytes free ✅ Expected behavior Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space. It should: Log a warning instead of terminating. Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag). Or skip log directory space checks for tmpfs mounts. 🔧 Workaround Creating a persistent log directory and overriding via systemd fixes the issue: mkdir -p /mnt/dietpi_userdata/jellyfin-logs chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs systemctl edit jellyfin Add: [Service] Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs" Then reload: systemctl daemon-reexec systemctl daemon-reload systemctl restart jellyfin After that, Jellyfin runs normally. 🧠 Additional context This affects many lightweight or NAS-oriented distros that keep /var/log in memory. The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64). It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check. 🧾 Suggested Fix In StorageHelper.TestCommonPathsForStorageCapacity(): Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC), or reduce the required threshold for /var/log/jellyfin. Reproducible: ✅ Always Severity: 💥 High (prevents startup on many embedded systems) Proposed labels: bug, linux, storage, debian, dietpi ### What is the expected _correct_ behavior? ### System Information - **Jellyfin version:** 10.11.1 (installed from repo.jellyfin.org) - **OS:** DietPi (Debian 12 Bookworm) - **Architecture:** x86_64 - **.NET Runtime:** 8.0 - **Systemd:** 252.25 (Debian stable) - **Install method:** apt (official Jellyfin repository) --- ### 🧩 Description Jellyfin fails to start on systems where `/var/log` is mounted as **tmpfs** (for example, DietPi, Raspbian, or OpenMediaVault). The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere. The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory `/var/log/jellyfin`. As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning. --- ### 💥 Error log System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space. Available: 49.9 MiB, Required: 512 MiB. at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...) at Jellyfin.Server.Program.StartApp(StartupOptions options) at Jellyfin.Server.Program.<Main>(String[] args) ============================================================================ Systemd: jellyfin.service: Main process exited, code=killed, status=6/ABRT --- ### ⚙️ Steps to reproduce 1. Install Jellyfin 10.11.1 on **DietPi** (Debian 12 Bookworm) 2. `/var/log` is mounted as `tmpfs` (e.g., 50 MB) 3. Start Jellyfin: ```bash systemctl start jellyfin Observe the crash: code=killed, signal=ABRT Check logs – insufficient free space error despite system having gigabytes free ✅ Expected behavior Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space. It should: Log a warning instead of terminating. Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag). Or skip log directory space checks for tmpfs mounts. 🔧 Workaround Creating a persistent log directory and overriding via systemd fixes the issue: mkdir -p /mnt/dietpi_userdata/jellyfin-logs chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs systemctl edit jellyfin Add: [Service] Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs" Then reload: systemctl daemon-reexec systemctl daemon-reload systemctl restart jellyfin After that, Jellyfin runs normally. 🧠 Additional context This affects many lightweight or NAS-oriented distros that keep /var/log in memory. The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64). It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check. 🧾 Suggested Fix In StorageHelper.TestCommonPathsForStorageCapacity(): Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC), or reduce the required threshold for /var/log/jellyfin. Reproducible: ✅ Always Severity: 💥 High (prevents startup on many embedded systems) Proposed labels: bug, linux, storage, debian, dietpi ### Jellyfin Server version 10.10.0+ ### Specify commit id _No response_ ### Specify unstable release number _No response_ ### Specify version number 10.11.1 ### Specify the build version 10.11.1 ### Environment ```markdown - OS: - Linux Kernel: - Virtualization: - Clients: - Browser: - FFmpeg Version: - Playback Method: - Hardware Acceleration: - GPU Model: - Plugins: - Reverse Proxy: - Base URL: - Networking: - Jellyfin Data Storage: - Media Storage: - External Integrations: ``` ### Jellyfin logs ```shell ### System Information - **Jellyfin version:** 10.11.1 (installed from repo.jellyfin.org) - **OS:** DietPi (Debian 12 Bookworm) - **Architecture:** x86_64 - **.NET Runtime:** 8.0 - **Systemd:** 252.25 (Debian stable) - **Install method:** apt (official Jellyfin repository) --- ### 🧩 Description Jellyfin fails to start on systems where `/var/log` is mounted as **tmpfs** (for example, DietPi, Raspbian, or OpenMediaVault). The process terminates immediately with a fatal error, even though the system has plenty of free disk space elsewhere. The problem is caused by a hardcoded minimum free space requirement (512 MB) in the log directory `/var/log/jellyfin`. As tmpfs partitions are intentionally small (often 50–100 MB), Jellyfin aborts startup instead of just logging a warning. --- ### 💥 Error log System.InvalidOperationException: The path /var/log/jellyfin has insufficient free space. Available: 49.9 MiB, Required: 512 MiB. at Jellyfin.Server.Implementations.StorageHelpers.StorageHelper.TestDataDirectorySize(...) at Jellyfin.Server.Program.StartApp(StartupOptions options) at Jellyfin.Server.Program.<Main>(String[] args) ============================================================================ Systemd: jellyfin.service: Main process exited, code=killed, status=6/ABRT --- ### ⚙️ Steps to reproduce 1. Install Jellyfin 10.11.1 on **DietPi** (Debian 12 Bookworm) 2. `/var/log` is mounted as `tmpfs` (e.g., 50 MB) 3. Start Jellyfin: systemctl start jellyfin Observe the crash: code=killed, signal=ABRT Check logs – insufficient free space error despite system having gigabytes free ✅ Expected behavior Jellyfin should not abort startup when /var/log/jellyfin is on tmpfs or has limited space. It should: Log a warning instead of terminating. Or allow adjusting the threshold (e.g., JELLYFIN_MIN_LOG_SPACE_MB or CLI flag). Or skip log directory space checks for tmpfs mounts. 🔧 Workaround Creating a persistent log directory and overriding via systemd fixes the issue: mkdir -p /mnt/dietpi_userdata/jellyfin-logs chown -R jellyfin:jellyfin /mnt/dietpi_userdata/jellyfin-logs systemctl edit jellyfin Add: [Service] Environment="JELLYFIN_LOG_DIR=/mnt/dietpi_userdata/jellyfin-logs" Then reload: systemctl daemon-reexec systemctl daemon-reload systemctl restart jellyfin After that, Jellyfin runs normally. 🧠 Additional context This affects many lightweight or NAS-oriented distros that keep /var/log in memory. The bug is reproducible on clean installs of DietPi Bookworm (x86_64, ARM64). It does not occur on Ubuntu 22.04, since its /var/log resides on disk and the system passes the free space check. 🧾 Suggested Fix In StorageHelper.TestCommonPathsForStorageCapacity(): Add a conditional skip for tmpfs mounts (statvfs.f_type == TMPFS_MAGIC), or reduce the required threshold for /var/log/jellyfin. Reproducible: ✅ Always Severity: 💥 High (prevents startup on many embedded systems) Proposed labels: bug, linux, storage, debian, dietpi ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information _No response_
OVERLORD added the bug label 2026-02-07 05:14:47 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EFjellyfin.db
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
Mirrored from GitHub Pull Request
 question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#7614
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?