Long attachment expiration are not working....

[ctschach]

🐞 Describe the bug
I do use my own server for personal notification. Therefore I've extended the expiration date for attachments via the config file:

attachment-expiry-duration: "336h"

This should give me a storage time of 14 days. Unfortunately this is not working. Attachements from 2+ days are not shown.

💻 Components impacted
Current version via docker running on Ubuntu 22.04 LTS

[wunter8]

Can you clarify what you mean by "attachments from 2+ days are not shown"?

[ctschach]

Attachments send via ntfy more than 2 days ago are not shown…the messages are.

[wunter8]

In which client? (Android, web, iOS, PWA)
If you access the link associated with the attachment, does it load?
Are the attachments still in the attachments directory and simply cannot be accessed via the link?

[ctschach]

I mainly use the PWA on MacOS, but it also happens on iOS.

But you are right, the attachments are gone form the attachment folder on the server. I only see todays attachments.

Could it be possible that my value is to high and therefore the application reverts back to the default?

[wunter8]

The default is 3h. Do you see anything in there that was created more than 3h ago? If not, it could be that the formatting in your server.yml file is slightly off, so your custom value might not be applied at all. I don't think there's any value that is "too high"

You can check your server.yml file using yamllint.com

[ctschach]

Hi Checked the config file and it's syntactically correct (I mean there is not much you can do wrong):

base-url: "https://ntfy.mydomain.net"
listen-http: ":2586"
cache-file: "/var/cache/ntfy/cache.db"
behind-proxy: true
manager-interval: "15m"
attachment-cache-dir: "/var/cache/ntfy/attachments"
attachment-total-size-limit: "10G"
attachment-file-size-limit: "15M"
attachment-expiry-duration: "336h"
visitor-attachment-total-size-limit: "500M"

auth-file: "/etc/ntfy/user.db"

smtp-sender-addr: "mail.mydomain.net:465"
smtp-sender-user: "smtp"
smtp-sender-pass: "secret"
smtp-sender-from: "[email protected]"
#smtp-server-listen: ":25"
#smtp-server-domain: "ntfy.sh"
#smtp-server-addr-prefix: "ntfy-"
keepalive-interval: "45s"
upstream-base-url: "https://ntfy.sh"
log-level: "info"
log-file: "/var/log/ntfy.log"

#Web Push keys generated. Add the following lines to your config file:
web-push-public-key: xxxxxxxxxx
web-push-private-key: xxxxxxxxxxx
web-push-file: /var/cache/ntfy/webpush.db
web-push-email-address: [email protected]

I checked the attachment folder. And the latest entry I had was yesterday at around 5:00pm and this was gone this morning.

Is there a way to log the attachment cleaning process? The current log file does not mention anything about it.

[ctschach]

So I now created a cron-job which will send a notification with an attached image to a new channel every hour. That will allow me to see how long attachments are kept. I'll report as soon as I have some data.

[ctschach]

Okay, so no matter what I set in the config file. It looks like 24h is the maximum „ attachment-expiry-duration“ I can use or differently said: no matter what I set as duration, 24h is the longest you can get. Even „just“ setting it to 48h will only give me 24h.

[wunter8]

Hmm. Do you have any tiers set up? (ntfy tier list)

[ctschach]

Hmm. Do you have any tiers set up? (ntfy tier list)

No

[wunter8]

Do values less than 24h work correctly?

[binwiederhier]

Maybe it's the new duration parsing logic 😬 -- I can check later.

Obviously though attachments will not outlive their messages. So cache-duration has to be as high as the attachment duration

[ctschach]

Obviously though attachments will not outlive their messages. So cache-duration has to be as high as the attachment duration

Okay, that's an interesting catch. But if I look that "cache-duration" has a default of 12h (and I've not changed this currently), why do attachments stay there for 24h.

But I've just increased the "cache-duration" to 48h and the same for the a "attachment-expiry-duration" - so let's see if this makes any difference

Do values less than 24h work correctly?

I'll test this also once I got some results from the above test.