Data Retention Job Fails with Permission Denied on File Deletion

Adit Yadav

Updated July 23, 2026 08:29

Applies to: Mattermost Server with data retention enabled; on-disk or network storage (including AWS EFS); any server version.

Symptoms: The data retention job fails with a permission denied error when deleting files. After fixing permissions, AWS EFS Console shows no change in storage size.

Confirmation status: Pending confirmation — engineer provided the fix but customer did not explicitly confirm resolution.

🛑 Problem

The Mattermost data retention job runs as the Mattermost process user (UID 2000 in containerized deployments). If directories under the data path were created with different ownership (e.g., from a migration or volume restore), the process cannot delete them.

Symptoms

error: doJob: Data retention job failed., DoFilesOnDisk: Unable to remove the directory.
unable to remove the directory <YYYYMMDD>: open /mattermost/data/<YYYYMMDD>/...: permission denied

Data retention job shows "Failed" in Policy Log.
Directories in /mattermost/data/ are owned by a different user.
After a successful job, AWS EFS Console may still show the same storage size (display lag — not a real issue).

✅ Solution

Step 1: Fix directory ownership

ls -la /mattermost/data/
chown -R 2000:2000 /mattermost/data/<affected_directory>

Replace 2000:2000 with the actual UID:GID of your Mattermost process user.

Step 2: Re-run the data retention job

System Console > Compliance > Data Retention Policies > Run Deletion Job Now. Confirm status shows "Success."

Step 3: Verify storage was freed

df -h /mattermost/data

Important: AWS EFS Console metrics may lag. Use df -h on the server for authoritative storage usage. Directories not named in YYYYMMDD format are never deleted by the data retention job.