How to check file changes in Linux

Unexpected file changes can explain a failed deployment, a service that restarted with different settings, or a security review that needs a timeline. Checking modification and metadata timestamps in Linux narrows the search to files that changed during the window that matters.

Linux keeps separate file timestamps. mtime moves when file contents change, while ctime moves when metadata changes, including permissions, ownership, group, link count, and many renames. The find command can filter by those timestamps across selected paths, and stat can confirm the timestamps and mode on one file.

Start with paths tied to the question instead of scanning the whole root filesystem. Configuration directories, local binary directories, user home directories, and writable temporary locations usually produce clearer signals than pseudo filesystems, package caches, and runtime directories. Creation time is filesystem-dependent, so treat Birth in stat as extra context when it appears, not the only proof.

Related: How to investigate a Linux intrusion
Related: How to check commands run by a user in Linux

Steps to check file changes in Linux:

  1. List files modified in the last 24 hours in the paths that matter. 
    $ sudo find /etc/ssh /etc/sudoers.d /etc/local-audit.conf /usr/local/bin -type f -mtime -1 -printf '%TY-%Tm-%Td %TH:%TM %p\n'
2026-06-13 10:18 /etc/ssh/sshd_config
2026-06-13 10:24 /etc/sudoers.d/deploy
2026-06-13 10:32 /etc/local-audit.conf
2026-06-13 10:47 /usr/local/bin/deploy-health-check

    -mtime -1 means the file content changed less than 24 hours ago. Replace the sample paths with the directories tied to the deployment, incident, or service under review.

  2. Filter the same paths to the known change window. 
    $ sudo find /etc/ssh /etc/sudoers.d /etc/local-audit.conf /usr/local/bin -type f -newermt '2026-06-13 10:00:00' ! -newermt '2026-06-13 11:00:00' -printf '%TY-%Tm-%Td %TH:%TM %p\n'
2026-06-13 10:18 /etc/ssh/sshd_config
2026-06-13 10:24 /etc/sudoers.d/deploy
2026-06-13 10:32 /etc/local-audit.conf
2026-06-13 10:47 /usr/local/bin/deploy-health-check

    -newermt compares modification time against literal dates, so it is better than guessing whole days when logs or deployment notes already provide a time range.

  3. Check metadata changes for the same paths. 
    $ sudo find /etc/ssh /etc/sudoers.d /etc/local-audit.conf /usr/local/bin -type f -cmin -60 -printf '%C+ %M %u:%g %p\n'
2026-06-13+11:29:01.0514150030 -rw-r--r-- root:root /etc/ssh/sshd_config
2026-06-13+11:29:01.0534150030 -rw-r--r-- root:root /etc/sudoers.d/deploy
2026-06-13+11:29:01.0544150030 -rw-r--r-- root:root /etc/local-audit.conf
2026-06-13+11:29:01.0554150030 -rwsr-xr-x root:root /usr/local/bin/deploy-health-check

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

  4. Review recent user-owned files without common cache and trash paths. 
    $ sudo find /home/ops -type f -mtime -1 -not -path '*/.cache/*' -not -path '*/.local/share/Trash/*' -printf '%TY-%Tm-%Td %TH:%TM %p\n'
2026-06-13 10:38 /home/ops/reports/deploy-notes.txt
2026-06-13 10:22 /home/ops/.ssh/authorized_keys

    Replace /home/ops with the account directory under review. On multi-user systems, scanning all of /home can produce unrelated editor, browser, and cache activity.

  5. Check writable temporary locations for recent executable files. 
    $ sudo find /tmp /var/tmp /dev/shm -type f -mtime -1 -perm /111 -printf '%TY-%Tm-%Td %TH:%TM %M %u:%g %p\n'
2026-06-13 10:41 -rwxr-xr-x root:root /tmp/collect-metadata.sh

    Do not run unknown executable files found in writable temporary directories. Inspect, hash, quarantine, or compare them from a controlled session instead.

  6. Inspect one suspicious file directly. 
    $ sudo stat /usr/local/bin/deploy-health-check
  File: /usr/local/bin/deploy-health-check
  size: 23        	Blocks: 8          IO Block: 4096   regular file
Device: 0,84	Inode: 3019390     Links: 1
Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2026-06-13 10:47:00.000000000 +0000
Modify: 2026-06-13 10:47:00.000000000 +0000
Change: 2026-06-13 11:29:01.055415003 +0000
 Birth: 2026-06-13 11:29:01.041415003 +0000

    Modify is the content timestamp, Change is the metadata timestamp, and Birth may be blank or unavailable on some filesystems.

  7. Hash the suspicious file for later comparison. 
    $ sudo sha256sum /usr/local/bin/deploy-health-check
2d6533a4b8ee139396de8d9bcdba99b01e9bdcd02db054a407e716bfbca5b64e  /usr/local/bin/deploy-health-check

    A checksum does not prove that a file is safe. It preserves a byte-for-byte value for comparison with a package database, known-good host, backup, or evidence record.
    Related: How to verify a checksum in Linux