Checking recent file changes in Linux helps explain unexpected service behavior, failed deployments, and signs of unauthorized access. A short timestamp-based scan often shows which configuration files, binaries, or user-owned files changed before the problem started.

Linux records several timestamps for each file. mtime tracks content changes, while ctime tracks metadata changes such as permissions, ownership, and renames. The find command can filter paths by those timestamps, and stat can confirm exactly what changed on a suspicious file.

Large filesystem scans create noise from restricted or fast-changing paths, especially under pseudo filesystems and cache directories. Starting with high-signal locations such as /etc, /boot, common binary paths, and the relevant user home directory usually produces clearer results. When a maintenance or incident window is known, -newermt is more precise than guessing with whole-day ranges.

Steps to check file changes in Linux:

  1. Open a terminal with access to sudo for the directories that need to be inspected.
    $ whoami
    root

    Normal users can scan their own files, but system paths such as /etc and /usr usually need elevated access.

  2. List files modified in the last 24 hours under high-signal system paths.
    $ sudo find /etc /boot /usr/local/bin /usr/bin /usr/sbin -type f -mtime -1 -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' 2>/dev/null | sort -r | head -n 10
    2026-04-14 08:33:00.0000000000 /usr/local/bin/deploy-health-check
    2026-04-14 08:12:00.0000000000 /etc/local-audit.conf
    2026-04-14 07:54:18.0000000000 /etc/ssh/sshd_config
    2026-04-14 07:49:02.0000000000 /etc/sudoers.d/deploy
    2026-04-14 07:41:36.0000000000 /usr/bin/needrestart

    -mtime -1 means less than 24 hours old. Use -daystart -mtime 1 when the goal is yesterday's changes rather than the last rolling 24-hour window.

  3. Narrow the results to an exact maintenance or incident window when the change timeline is known.
    $ sudo find /etc /usr/local/bin -type f -newermt '2026-04-14 08:00:00' ! -newermt '2026-04-14 08:40:00' -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' 2>/dev/null | sort
    2026-04-14 08:12:00.0000000000 /etc/local-audit.conf
    2026-04-14 08:33:00.0000000000 /usr/local/bin/deploy-health-check

    -newermt accepts a literal date and time, which makes it useful when a deployment, cron job, or suspicious login already has a known start time.

  4. Check recent metadata changes to catch owner, group, permission, or rename activity even when file contents did not change.
    $ sudo find /etc -type f -cmin -60 -printf '%C+ %p\n' 2>/dev/null | sort -r | head -n 10
    2026-04-14+08:19:44.0000000000 /etc/sudoers.d/deploy
    2026-04-14+08:17:01.0000000000 /etc/ssh/sshd_config
    2026-04-14+08:12:00.0000000000 /etc/local-audit.conf

    -ctime and -cmin report status changes, not only content writes. A chmod, chown, or rename can move ctime without updating mtime.

  5. Review recent changes inside user home directories while pruning common cache and trash locations.
    $ sudo find /home -type f -mtime -1 -not -path '*/.cache/*' -not -path '*/.local/share/Trash/*' -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' 2>/dev/null | sort -r | head -n 10
    2026-04-14 08:06:32.0000000000 /home/ops/.ssh/authorized_keys
    2026-04-14 07:58:14.0000000000 /home/ops/reports/deploy-notes.txt

    Replacing /home with a specific user directory reduces noise on multi-user systems.

  6. Check writable temporary locations for recently written executable files.
    $ sudo find /tmp /var/tmp /dev/shm -type f -mtime -1 -perm /111 -printf '%TY-%Tm-%Td %TH:%TM:%TS %M %u:%g %p\n' 2>/dev/null | sort -r | head -n 10
    2026-04-14 08:27:11.0000000000 -rwxr-xr-x root:root /tmp/deploy-health-check
    2026-04-14 08:03:49.0000000000 -rwx------ ops:ops /dev/shm/run-once.sh

    Do not execute unknown files found in writable temporary directories. Treat them as artifacts to inspect, hash, quarantine, or compare against known-good software.

  7. Review recently changed privileged binaries in the common system binary paths.
    $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin -type f \( -perm -4000 -o -perm -2000 \) -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM:%TS %M %u:%g %p\n' 2>/dev/null | sort -r | head -n 20
    2026-04-14 08:33:00.0000000000 -rwsr-xr-x root:root /usr/local/bin/deploy-health-check

    Keeping the search on the usual binary directories avoids the prune-heavy full-root scan that often introduces noise from pseudo filesystems and container mounts.

  8. Inspect the timestamps and ownership on a suspicious file directly.
    $ sudo stat /usr/local/bin/deploy-health-check
      File: /usr/local/bin/deploy-health-check
      Size: 18        	Blocks: 8          IO Block: 4096   regular file
    Device: 0,90	Inode: 2905444     Links: 1
    Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2026-04-14 08:33:00.000000000 +0000
    Modify: 2026-04-14 08:33:00.000000000 +0000
    Change: 2026-04-14 01:08:09.872351005 +0000
     Birth: 2026-04-14 01:08:09.870351005 +0000

    The Birth line may show - on filesystems that do not record creation time. Change is the metadata timestamp, not a synonym for content modification.

  9. Hash the suspicious file so it can be compared with a known-good copy or another host later.
    $ sudo sha256sum /usr/local/bin/deploy-health-check
    b4d644d4279594903f1a9911956432d9473041f2984fc6014c14d7402c7d126c  /usr/local/bin/deploy-health-check

    A saved checksum supports later comparison, package verification, or evidence handling without reopening the file repeatedly.