Allow configuring mandatory share expiration

[waza-ari]

Is your feature request related to a problem? Please describe.

After having maintained a Nextcloud installation for more than 10 years, it became pretty apparent that, over time, public shares get created and forgotten. Especially in an environment where people come and go (e.g. a non profit organization such as ours), that ends up various problems.

For example, we regularly have questions like:

• who again created the share of document XYZ linked on the homepage?
• this shared link XYZ on Wiki page ABC no longer works, who created it and which file did it refer to?
• someone shared a folder they were not supposed to share, and the link somehow got to people that should not have access to the files

Ultimately, we end up with a plethora of shared public link shares, often so files that are sensitive, with no overview who created them, what they were used for, and if its a security issue or not. At the

Describe the solution you'd like

We would like to propose adding an ability further administrative control to public link shares. As of today, it is possible to enforce a password to be set, however that applies to all link shares and lacks flexibility.

Ideally, we'd be able to add an administrative setting that - if enabled - enforces the user to set an expiration date. The maximum duration is configurable using a second setting.

• Option 1: two environment variables applying to everything, e.g. SHARING_PUBLIC_SHARE_MUST_HAVE_EXPIRY_DATE and SHARING_PUBLIC_SHARE_MAX_SHARE_DURATION or similar. The frontend would need to be adjusted to handle those cases, I'm not sure how that would affect sharing on the app side
• Option 2: even more flexibility would be possible by allowing these settings on a per Storage Space level. This way, user spaces could retain the freedom they currently have, while it would be possible to define stricter policy for spaces containing more sensitive data.

Describe alternatives you've considered

Alternatively it could be possible to handle this as part of user permissions - e.g. have a certain role that is allowed to create shares with unlimited duration, others would be forced to set an expiration date.

Additional context

In the past, the open sharing policy has led to security incidents, where share links have been handled without proper care by some users, leading to files being publicly available that should not have been. While this is ultimately within the responsibility of the user creating the share, having a forced expiration would help reducing this risk significantly.

[dj4oC]

Hi @waza-ari

Thank you for bringing this up and for sharing your long-standing experience maintaining a Nextcloud instance - your insights are incredibly valuable and resonate with challenges we’ve seen in similar environments. We’d like to offer a few reflections and an invitation to collaborate:

1. Why public shares and not guest users via Keycloak self-registration and ownCloud light users?
   In ownCloud, we’ve focused on improving security and traceability by supporting federated identities and lightweight guest users (e.g. via Keycloak with self-registration flows). These guests can be fully auditable and provide fine-grained access control compared to anonymous public shares. We’d be happy to share more on how to configure this if you’re interested - it’s a great step for organizations handling sensitive data or operating under strict compliance requirements.

2. Upcoming Features: Enforced Share Expiry and Auto-Deletion (GDPR Art. 9)
   We’re currently considering to develop two features with a focus on compliance and risk reduction:

• Enforced expiration dates for public shares with configurable max durations.
• Enforced deletion of files after a configurable retention period, especially when flagged as containing sensitive (e.g. GDPR Art. 9) data.

These would be configurable globally or per Space Category to allow for stricter policies in sensitive areas while preserving user flexibility elsewhere - very much in line with what you’ve proposed.

3. Would you like to collaborate with us on this development?
   Your real-world experience and use case are precisely what we need to validate and refine this functionality. If you’re interested, we’d love to collaborate with you - either via feedback rounds, design discussions, or even hands-on testing once prototypes are ready. Let us know how you’d prefer to engage!

4. How can we help you have a great community experience?
   We’re committed to building a strong and transparent community around ownCloud. If you have feedback on how we can support you better - whether through improved documentation, more accessible discussions, feature visibility, or anything else - we’re all ears.

Thanks again for taking the time to share this. Looking forward to your thoughts!

\cc @marcelmockkw @DeepDiver1975 @d7oc @kobergj

[waza-ari]

Hi David,

thanks for your answer and also thanks for the gentle reminder! I got caught up on work and somewhat missed this one. Let me go through your answers:

1. Implementing guest users is certainly a possibility, and might be very much appropriate for very sensitive data as you suggested. It comes at a price though (mainly looking at complexity and UX) and may not be possible in certain environments. We already have a self-service registration flow in place, those "guests users" as we call them are created in Keycloak and could be used for link sharing in OCIS, too. They however come with a range of other privileges and trigger certain internal actions as well (e.g. invitation to link their slack profile, welcome messages and so on), so this flow is not really applicable to our situation. It's a very nice and very much welcome option though.

2. this sounds absolutely awesome and would fulfill our needs from what I can tell. I'm still debating myself if there's a point to also tie the enforced expiration to user permissions, e.g. have certain configurable groups that can override those restrictions. That might come in handy but obviously also introduces more complexity both on the code side and user side, so not sure thats worth it. I suppose it can be sorted by using different spaces, if the decision is made to implement that feature per space (which I'd highly prefer)

3. I'm more than happy to participate if time permits. My Go language skills are nearly non-existent, so I wouldn't really be able to contribute in code, but I'd me happy to engage in discussions and feedback rounds, and I'm also happy to test prototypes, also within our organization.

4. IMHO the way you approach the project here on Github already strikes me as outstandingly open. That said, I haven't been involved much and/or contributing much here, so it's hard for me to tell. If I find any tangible and actionable feedback I'll be happy to share though

Thanks again!

[dj4oC]

Hi @waza-ari
Thanks a lot for your reply - and no worries at all, we know how easily things can get buried when juggling multiple projects!

We really appreciate your elaboration on the guest user flow and totally understand your point: even when technically feasible, integrating such flows into existing org processes can bring unintended side effects - which we did not consider before. Your insight helps us understand that even well-meant features need to be optional and adaptable to diverse environments - exactly the kind of context that makes community input so valuable.

We’re glad to hear the planned features align with your needs! The idea of permission-based overrides is indeed something we’ve considered. You’re right - it introduces added complexity, but it could be useful for larger environments where administrative users need more flexibility. That said, we agree: per-space policies may provide a cleaner solution without overloading the permission model. We’ll make sure to keep that balance in mind during the design phase.

We’d absolutely love to have you participate in feedback and testing rounds. No need for Go skills - real-world insight and hands-on testing are just as crucial. We’ll reach out as soon as we have early prototypes or design models to review.

Thanks as well for the kind words about how we work here on GitHub. Please feel free to keep the feedback flowing, and don’t hesitate to raise issues or join other discussions if you spot anything that could be improved.

Looking forward to continuing this with you!
\cc @marcelmockkw @kobergj @d7oc @DeepDiver1975