Files uploaded to AmazonS3/MinIO get expiresAt and disappear despite URL expiry & retention disabled

[MicoDan]

Description:

I’m running Rocket.Chat version 8.0.1 in a Docker container and MinIO also in a Docker container for file uploads. Files uploaded via Rocket.Chat (store: AmazonS3:Uploads) are automatically assigned an expiresAt timestamp and become unavailable after ~1 day, even though:

• URL expiration is set to 0
• File retention policies are disabled

Observed Behavior:

• Uploaded files work immediately.
• After ~1 day, files stop being downloadable/previewable.
• In MongoDB, rocketchat_uploads documents always have expiresAt = uploadedAt + ~1 day.
• expiresAt persists for new uploads even after disabling URL expiry & retention policies.

What I’ve Checked / Tried:

• FileUpload_S3_URLExpiryTimeSpan = 0 in admin settings
• Disabled all retention policies
• Verified Mongo indexes; expiresAt index is not TTL
• Only one Rocket.Chat + Mongo instance running

Questions:

1. Should Rocket.Chat continue setting expiresAt when URL expiry and retention are disabled?
2. How can uploads remain accessible indefinitely with AmazonS3/MinIO?
3. Are there server-side jobs or TTL configs outside Mongo that delete files based on expiresAt?
4. If this is a bug, which part of the code controls setting expiresAt for S3 uploads?

[Mahi1801]

Hi @MicoDan ,
I'd like to work on this bug. After looking into it, the issue seems to be that expiresAt is being set unconditionally during S3/MinIO uploads, regardless of whether URL expiry is actually enabled (FileUpload_S3_URLExpiryTimeSpan = 0).

My proposed fix would be to add a guard in the S3 upload handler-only setting expiresAt when the expiry timespan is configured and greater than 0, and leaving it null/undefined otherwise.

Could someone confirm:

1. Is this the expected root cause?
2. Are there any server-side cron jobs or Meteor jobs that also clean up files based on expiresAt that would need to be updated?

Happy to submit a PR once I get a green light. Thanks!

[KevLehman]

Can you share how are you uploading your files?

[MicoDan]

Hi @Mahi1801 , There isn't a code snippet that sets expiresAt, it only passes URLExpiryTimeSpan into the S3 store. So I think Rocket.Chat is only reading FileUpload_S3_URLExpiryTimeSpan and passing it into the S3 store config as URLExpiryTimeSpan. Which should theoretically work, but it doesn’t, uploads are still being assigned a 1 day expiresAt value regardless of the configured URLExpiryTimeSpan.

Check it out : Rocketchat repo link

And also I don't think Rocket.Chat normally runs a cron/Meteor job that deletes S3/MinIO objects just because rocketchat_uploads.expiresAt is reached, cleanup is driven by Retention Policy / pruning settings, not that field. The only “server side cleanup” I separately checked is MinIO lifecycle/ILM rules and I don't have any so that's not the issue

[KevLehman]

That doesn't answer my question.

[MicoDan]

Hi @KevLehman , you'll find the upload file code snippet below

async uploadFile(file, description = '') {
  const formData = new FormData();
  formData.append('file', file, file.name); 
  formData.append('msg', description || '');

  const uploadUrl = `${this.serverUrl}/api/v1/rooms.media/${this.roomId}`;

  const response = await fetch(uploadUrl, {
    method: 'POST',
    headers: {
      'X-Auth-Token': this.authToken,
      'X-User-Id': this.userId
    },
    body: formData
  });

  if (!response.ok) {
    const text = await response.text();
    throw new Error(`Upload failed: ${response.status} ${text}`);
  }

  const data = await response.json();

  return {
    fileId: data.file._id,
    fileUrl: data.file.url
  };
}

[KevLehman]

rooms.media uploads the files as unconfirmed by default. You need to confirm them by sending a message that references it with mediaConfirm endpoint.

By default, unconfirmed files are removed after 1 day. Confirmed files are not removed automatically (except with retention policy enabled)

If that answers your question, please close the issue. thx

[MicoDan]

@KevLehman This worked, the files were being uploaded as unconfirmed, which explains why they became unavailable after about 24 hours.

Thanks a lot for pointing me in the right direction, I really appreciate the help.