starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 08:26:00 +02:00

[GH-ISSUE #1053] Long attachment expiration are not working.... #738

New issue

Open

opened 2026-05-07 00:27:01 +02:00 by BreizhHardware · 15 comments

BreizhHardware commented

2026-05-07 00:27:01 +02:00

Owner

Originally created by @ctschach on GitHub (Mar 12, 2024).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1053

🐞 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

Originally created by @ctschach on GitHub (Mar 12, 2024). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1053 :lady_beetle: **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. :computer: **Components impacted** Current version via docker running on Ubuntu 22.04 LTS

BreizhHardware added the

🪲 bug

server

labels

2026-05-07 00:27:01 +02:00

BreizhHardware commented

2026-05-07 00:27:02 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 12, 2024):

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

@wunter8 commented on GitHub (Mar 12, 2024): Can you clarify what you mean by "attachments from 2+ days are not shown"?

BreizhHardware commented

2026-05-07 00:27:02 +02:00

Author

Owner

@ctschach commented on GitHub (Mar 12, 2024):

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

@ctschach commented on GitHub (Mar 12, 2024): Attachments send via ntfy more than 2 days ago are not shown…the messages are.

BreizhHardware commented

2026-05-07 00:27:03 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 12, 2024):

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?

@wunter8 commented on GitHub (Mar 12, 2024): 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?

BreizhHardware commented

2026-05-07 00:27:03 +02:00

Author

Owner

@ctschach commented on GitHub (Mar 12, 2024):

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?

@ctschach commented on GitHub (Mar 12, 2024): 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?

BreizhHardware commented

2026-05-07 00:27:03 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 12, 2024):

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

@wunter8 commented on GitHub (Mar 12, 2024): 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

BreizhHardware commented

2026-05-07 00:27:03 +02:00

Author

Owner

@ctschach commented on GitHub (Mar 13, 2024):

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: "ntfy@mydomain.net"
#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: ntfy@mydomain.net

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 commented on GitHub (Mar 13, 2024): 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: "ntfy@mydomain.net" #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: ntfy@mydomain.net ``` 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.

BreizhHardware commented

2026-05-07 00:27:03 +02:00

Author

Owner

@ctschach commented on GitHub (Mar 13, 2024):

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 commented on GitHub (Mar 13, 2024): 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.

BreizhHardware commented

2026-05-07 00:27:03 +02:00

Author

Owner

@ctschach commented on GitHub (Mar 14, 2024):

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.

@ctschach commented on GitHub (Mar 14, 2024): 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.

BreizhHardware commented

2026-05-07 00:27:04 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 14, 2024):

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

@wunter8 commented on GitHub (Mar 14, 2024): Hmm. Do you have any tiers set up? (`ntfy tier list`)

BreizhHardware commented

2026-05-07 00:27:04 +02:00

Author

Owner

@ctschach commented on GitHub (Mar 14, 2024):

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

@ctschach commented on GitHub (Mar 14, 2024): > Hmm. Do you have any tiers set up? (`ntfy tier list`) No

BreizhHardware commented

2026-05-07 00:27:04 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 14, 2024):

Do values less than 24h work correctly?

@wunter8 commented on GitHub (Mar 14, 2024): Do values less than 24h work correctly?

BreizhHardware commented

2026-05-07 00:27:04 +02:00

Author

Owner

@binwiederhier commented on GitHub (Mar 14, 2024):

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

@binwiederhier commented on GitHub (Mar 14, 2024): 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

BreizhHardware commented

2026-05-07 00:27:04 +02:00

Author

Owner

@ctschach commented on GitHub (Mar 14, 2024):

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.

@ctschach commented on GitHub (Mar 14, 2024): > 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.

BreizhHardware commented

2026-05-07 00:27:04 +02:00

Author

Owner

@Mat-DB commented on GitHub (Aug 23, 2024):

Any updates on this?

@Mat-DB commented on GitHub (Aug 23, 2024): Any updates on this?

BreizhHardware commented

2026-05-07 00:27:04 +02:00

Author

Owner

@xi-ao commented on GitHub (Mar 24, 2026):