~ / topics / Data & Protocols
$man file-systems

File Systems

In brief: Every file carries dates (when it was created, changed, read), and each file system stores those dates in a fixed number of bits. Some older formats run out in 2038 (ext2, ext3, older XFS), some in 2040 (Apple's HFS+), 2106 (NFS version 3) or 2107 (FAT, used on USB sticks and SD cards). Modern formats like NTFS, APFS, Btrfs, ZFS and properly configured ext4 and XFS are good for centuries. A file system can be safe in its newest version but still unsafe on a disk that was formatted years ago with old settings.

Risk level Medium (High on embedded devices with ext3/small-inode ext4 or non-bigtime XFS)
Status ext4 (256-byte inodes) and XFS bigtime fixed; ext2/ext3 and HFS+ formats cannot be fixed in place; existing volumes need checking
Last reviewed 2026-10-21

2038 status at a glance

  • At risk Confirmedext2 / ext3 file systemsThese use a fixed 128-byte inode with 32-bit signed seconds.Do: Reformat as ext4 with 256-byte inodes.
  • At risk Confirmedext4 created with 128-byte inodesThere is no room for the extra epoch bits. This is common in small and embedded images and older mke2fs profiles.Do: Check with tune2fs -l. Back up, recreate with mkfs.ext4 -I 256, and restore.
  • At risk ConfirmedXFS without the bigtime featureThe classic on-disk format ends in January 2038. Volumes made with older xfsprogs lack bigtime.Do: Upgrade offline with xfs_admin -O bigtime=1 (kernel 5.10+).
Not affected or different deadline (4), and why

Full risk register →Need help assessing your systems? →

Overview

A file-system timestamp limit is an on-disk format limit. Upgrading the kernel does not change data already written, and in many cases a volume must be converted or reformatted to gain a larger range. Linux makes this visible: since commit f8b92ba67c5d (merged after Linux 5.3-rc6, so first released in 5.4), mounting a file system that cannot store timestamps 30 years into the future logs a warning such as:

ext4 filesystem being mounted at /boot supports timestamps until 2038 (0x7fffffff)

The warning reuses the 30-year horizon that settimeofday() applies and was meant to push users toward ext4 rather than ext3 [1][2]. Arnd Bergmann's 2020 y2038 pull request notes that even after the kernel was fixed, "file systems with on-disk timestamps using signed 32-bit seconds" keep the 2038 problem [3].

Embedded devices are most exposed, because they often use ext2/ext3 or small-inode ext4 on flash, and FAT for removable media (see Devices-and-Embedded-Systems).

Technical details

ext2, ext3 and ext4

XFS

Btrfs

Btrfs stores btrfs_timespec as a 64-bit seconds field plus a 32-bit nanoseconds field [11]. Not affected by 2038.

NTFS

NTFS records times in UTC as FILETIME: "a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)" [12]. Treated as a signed 64-bit value, that runs to about the year 30828 (derived arithmetic). Not affected.

FAT (FAT12/16/32) and DOS timestamps

FAT directory entries store the year in 7 bits counted from 1980. The Linux driver states: "FAT can only support year between 1980 to 2107" and clamps later dates to 2107-12-31 [13]. FAT also records local time rather than UTC [12]. The same DOS date format is used inside ZIP files (see File-Formats-and-Protocols).

HFS and HFS+

HFS+ stores dates as "unsigned 32-bit integers (UInt32) containing the number of seconds since midnight, January 1, 1904, GMT", and "the maximum representable date is February 6, 2040 at 06:28:15 GMT" [14]. Classic HFS uses the same seconds-since-1904 base but in local time [14]. The 2040 limit is a format limit; the fix is migration to APFS.

APFS

APFS stores timestamps as 64-bit nanoseconds since 1970-01-01 UTC and is described as "Y2K38 safe" [15]. Sources disagree on whether the field is signed (range 1677–2262) or unsigned (up to about 2554) [15][16]; either way it is far beyond 2038.

ZFS

OpenZFS stores times internally as 64-bit values; a 2020 Linux 5.6 compatibility commit replaced remaining time_t uses with uint64_t, "which is already how ZFS internally handled these values" [17]. An early ZFS on Linux issue (#487, "Enable 64-bit timestamps") tracked a 32-bit restriction that blocked setting dates after 2038 on Linux [18]. Kaspersky lists ZFS, F2FS, NTFS and ReFS among file systems with 64-bit timestamps [19].

NFS

NFSv3 (RFC 1813) carries times as two uint32 fields, seconds and nanoseconds since 1970 [20]. Because the seconds are unsigned, NFSv3 timestamps "reach until 2106, but don't go back before 1970" [21]. A 2014 proposal to reuse spare nanosecond bits for extra seconds was not adopted [21]. Kaspersky flags NFSv2 and NFSv3 as using an outdated time format [19]. NFSv4 uses a 64-bit seconds field (per RFC 7530; not re-checked for this page).

Affected versions / products

File system On-disk time field Epoch Max date Fix
ext2 / ext3 (128-byte inode) 32-bit signed seconds 1970 2038-01-19 [4] Reformat as ext4 with 256-byte inodes
ext4, 128-byte inodes 32-bit signed seconds 1970 2038-01-19 [4][7] Backup, mkfs.ext4 -I 256, restore [7]
ext4, ≥ 256-byte inodes 34-bit seconds + 30-bit ns 1970 2446-05 [4] —
XFS V5 without bigtime 32-bit signed seconds 1970 2038-01-19 xfs_admin -O bigtime=1 (kernel ≥ 5.10) [9]
XFS with bigtime 64-bit ns 1901 (offset) 2486-07 [10] Default from xfsprogs 5.15 [9]
Btrfs 64-bit s + 32-bit ns 1970 Effectively unlimited [11] —
NTFS 64-bit 100-ns ticks 1601 ~30828 (derived) [12] —
FAT12/16/32 7-bit year, 2-s resolution 1980 2107-12-31 [13] Use exFAT/other where possible
HFS+ 32-bit unsigned seconds 1904 2040-02-06 06:28:15 GMT [14] Migrate to APFS
APFS 64-bit ns 1970 2262 or later [15][16] —
ZFS 64-bit 1970 Effectively unlimited [17] —
NFSv3 (protocol) 32-bit unsigned seconds 1970 2106-02-07 [20][21] Use NFSv4

Risk & compliance notes

Detection & mitigation

# Kernel warnings at mount time
dmesg | grep -i "timestamps until"

# ext2/3/4: inode size
for d in $(lsblk -rno PATH,FSTYPE | awk '$2 ~ /^ext[234]$/ {print $1}'); do
  echo "$d: $(tune2fs -l "$d" 2>/dev/null | grep 'Inode size')"; done

# XFS: bigtime flag
xfs_info /mountpoint | grep -o 'bigtime=[01]'

# Functional test on a scratch volume
touch -d '2040-01-01 00:00:00 UTC' testfile && stat testfile

See Testing-and-Detection and Remediation-Guide.

See also

References

  1. Re: [Y2038] [PATCH 04/20] mount: Add mount warning for impending timestamp expiry — LKML, 2019-08 — origin and rationale of the mount warning.
  2. Warnings about filesystem timestamp support until 2038 — LKML, 2020-08 — refers to commit f8b92ba67c5d.
  3. Arnd Bergmann, "[GIT PULL] y2038: core, driver and file system changes" — LKML, 2020-01-29 — file systems with signed 32-bit timestamps remain affected.
  4. ext4 Data Structures and Algorithms: Index Nodes — Linux kernel documentation — 128 vs 256-byte inodes, extra epoch bits, May 2446.
  5. Darrick J. Wong, mke2fs patch: 256-byte inodes for small file systems — linux-ext4 Patchwork, 2021-08-11 — default change and warning for 128-byte inodes.
  6. Ubuntu bug 1881935 — foundations-bugs list, 2020-06 — minimum inode size 256 for Y2038.
  7. François Marier, "Upgrading an ext4 filesystem for the year 2038" — feeding.cloud.geek.nz, 2021-05-08 — warning text, tune2fs check, reformat procedure.
  8. EXT3 file-system driver to be removed from the Linux kernel — Phoronix — ext3 driver removal in Linux 4.3.
  9. XFS — Gentoo Wiki — bigtime in kernel 5.10, default in xfsprogs 5.15, xfs_admin -O bigtime=1.
  10. XFS file-system with Linux 5.10 punts year 2038 problem to the year 2486 — Phoronix, 2020 — bigtime range Dec 1901–Jul 2486; not default at introduction.
  11. BTRFS_TIME struct reference — The Sleuth Kit 4.15 API docs — 64-bit seconds and 32-bit nanoseconds (seen in search results).
  12. FILETIME structure (minwinbase.h) — Microsoft Learn — 100-ns intervals since 1601; FAT local time vs NTFS UTC.
  13. fs/fat/misc.c — Android common kernel (Linux FAT driver) — 1980–2107 range, 7-bit year.
  14. Technical Note TN1150: HFS Plus Volume Format — Apple Developer — UInt32 seconds since 1904; max 2040-02-06 06:28:15 GMT.
  15. Jonathan Levin, OBTS v1 presentation — 2018 — APFS nanosecond timestamps, "Y2K38 safe" (seen in search results); see also dfdatetime: Date and time values (signed range 1677–2262).
  16. Be careful when interpreting APFS timestamps — The Eclectic Light Company, 2025-10-24 — describes APFS timestamps as unsigned 64-bit ns (seen in search results).
  17. Brian Behlendorf, "Linux 5.6 compat: time_t" — OpenZFS commit (mirror) — ZFS internally uses uint64_t for times (seen in search results).
  18. Enable 64-bit timestamps, issue #487 — openzfs/zfs on GitHub — early 32-bit timestamp restriction on ZFS on Linux.
  19. Stan Kaminsky, "Epochalypse Now — or how to deal with Y2K38" — Kaspersky, 2026-01-19 — file-system summary (ZFS, F2FS, NTFS, ReFS safe; ext2/3 vulnerable; NFSv2/3 outdated).
  20. RFC 1813 (NFS Version 3) basic data types — Connected: An Internet Encyclopedia mirror — nfstime3 as two uint32 fields (seen in search results).
  21. Arnd Bergmann on NFSv3 timestamps — LKML via lore.kernel.org, 2014 — NFSv3 reaches 2106, not before 1970; extension proposal (seen in search results).
  22. Considerations in adopting RHEL 9, Chapter 11: File systems and storage — Red Hat documentation — RHEL 9 mkfs.xfs enables bigtime and inobtcount by default; RHEL 8 mount incompatibility; xfs_admin upgrade; ext4 beyond 2038 with inodes larger than 128 bytes.