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' preview 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

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?

[mg1986jp]

The expiresAt field on uploaded files is controlled by the FileUpload_S3_URLExpiryTimeSpan setting, but setting it to 0 doesn't mean "no expiry" — in older versions of Rocket.Chat it was interpreted as "use default" (which was typically 86400 seconds / 1 day). This changed in more recent versions but behavior can be inconsistent.

Here's what's likely happening:

1. Rocket.Chat generates presigned S3/MinIO URLs for file access. The URLExpiryTimeSpan controls how long those URLs are valid. When the URL expires, the file isn't deleted — it just can't be accessed via the old URL.

2. The expiresAt field in MongoDB isn't a TTL index (you confirmed this), so files aren't being deleted from MinIO. They're just inaccessible because the presigned URL expired.

Fix:

Set FileUpload_S3_URLExpiryTimeSpan to a very large number instead of 0:

Admin → File Upload → Amazon S3 → URL Expiry Time Span → 31536000

That's 1 year in seconds. The URLs will still technically expire, but effectively last forever.

Alternative — make the MinIO bucket publicly readable:

If your MinIO instance is internal/trusted, set the bucket policy to allow public reads:

mc anonymous set download myminio/rocketchat-uploads

Then in Rocket.Chat settings:

• Set FileUpload_S3_URLExpiryTimeSpan to 0
• Enable FileUpload_S3_Proxy_Uploads — this makes Rocket.Chat proxy file downloads through its own server instead of redirecting to presigned URLs

With proxy mode + public bucket, the presigned URL expiry becomes irrelevant because Rocket.Chat fetches the file server-side using its configured credentials.

To verify files still exist in MinIO:

mc ls myminio/rocketchat-uploads/

If the files are there, it's purely a URL expiry issue, not a deletion issue.

[DonQuinleone]

expiresAt isn't related to the S3 URL expiry or to retention at all, which is why changing those settings made no difference. It's Rocket.Chat's marker for a temporary upload: a file that has been uploaded but not yet attached to a sent message.

How it works (same in 8.0.1 and current develop):

1. POST /api/v1/rooms.media/:rid stores the file and sets expiresAt to upload time + 24 hours.
2. POST /api/v1/rooms.mediaConfirm/:rid/:fileId sends the message for that file and then $unsets expiresAt (Uploads.confirmTemporaryFile).
3. A cron job, temporaryUploadCleanup, runs at minute 31 of every hour, finds uploads whose expiresAt has passed and deletes them through the file store. For the AmazonS3 store that is a real deleteObject on the bucket, so the object is gone from MinIO, not just hidden.

So the setting you'd want doesn't exist: confirmed uploads simply never have expiresAt. If yours keep it, step 2 isn't completing for them. FileUpload_S3_URLExpiryTimeSpan only controls how long the presigned download URLs are valid; it has nothing to do with this.

Things to check:

• In the browser dev tools (Network tab), send a file and look for POST /api/v1/rooms.mediaConfirm/.... Is it there, and does it return 200? A reverse proxy rule, a size or body limit, or a server-side error on that call would leave every file temporary while the upload itself looks fine.
• If files arrive via a bot, integration or script rather than the web/desktop client, make sure it calls rooms.mediaConfirm after rooms.media.
• Check the server logs around the time of an upload for errors from rooms.mediaConfirm.

To see which uploads are still marked temporary:

db.rocketchat_uploads.find(
  { expiresAt: { $exists: true } },
  { name: 1, rid: 1, userId: 1, uploadedAt: 1, expiresAt: 1 }
)

As a stopgap while you find the cause, you can clear the marker on uploads that really are attached to a message (this is exactly what confirmTemporaryFile does), so the cron leaves them alone:

db.rocketchat_uploads.find({ expiresAt: { $exists: true } }).forEach((u) => {
  const msg = db.rocketchat_message.findOne(
    { $or: [{ 'file._id': u._id }, { 'files._id': u._id }] },
    { _id: 1 }
  );
  if (msg) {
    db.rocketchat_uploads.updateOne({ _id: u._id }, { $unset: { expiresAt: 1 } });
  }
});

Take a backup first. Files the cron has already removed are gone from the bucket unless you have versioning enabled on it.