How to Restrict Public Link Expiration Dates in ownCloud Server

If a public ownCloud link stays usable longer than your organization intended, changing the date on one file is not enough. An administrator can set a default expiration for public links and enforce that value as the maximum, so link creators may choose an earlier date but cannot extend access beyond the policy. The instructions below follow the ownCloud Server (Classic) 11.0 administration documentation. ownCloud Infinite Scale has a different web interface and configuration model; do not assume the Classic settings path applies there.

Know what the expiration setting controls

A public link is a URL that lets someone access a shared file or folder without being an ownCloud user. The link’s permissions determine what that visitor can do; its expiration date determines how long the link remains available. In ownCloud Server, the selected public-link expiration takes effect at the end of the specified day.

A default expiration pre-fills a date or period for a new share. Depending on the policy, users might be able to change or remove that default. Enforce as maximum expiration date turns the configured default into a ceiling: users can choose a shorter lifetime, but not a later date. It does not mean every link must expire on the exact same day.

These controls are separate from expiration policies for shares with local users, groups, or remote users. Configure the public-link section when your goal is to limit links for people outside the ownCloud account system. The ownCloud Server 11.0 file-sharing administration guide documents the setting and its maximum-date behavior.

Before you change the policy

• Confirm the product. These steps are for ownCloud Server Classic. If your interface has Spaces and a right-hand Shares sidebar, you may be using Infinite Scale; its user guide describes a different sharing flow. Ask the instance administrator to consult the matching Infinite Scale administration documentation rather than searching for the Classic checkbox.
• Confirm administrator access. The expiration rule is in administrative Sharing settings, not in a regular user’s file-sharing panel. You need an account permitted to change server settings.
• Choose a workable limit. Decide how long external recipients normally need access, then set a maximum that fits that use. For example, a team that sends short-lived review links may choose a shorter window than one that shares project materials for a month. Those are policy examples, not ownCloud defaults or recommendations from the vendor.

Tell link owners what will change before you enforce the rule. They may need to issue a fresh link with a shorter date when the current workflow expects longer access.

Set a maximum expiration date for public links

1. Open the administrator Sharing settings. Sign in with an administrator account and go to the administrative settings page, then open Sharing. Exact navigation wording can vary by release or translation, but the option is in the admin Sharing settings described in the Server manual.
2. Find the public-link policy. In the section for allowing users to share via link, locate Set Default Expiration Date of Public Link Shares. This setting is specifically for public links. Do not change similarly named settings for user, group, or remote shares unless you intend to change those policies too.
3. Enable the default and set its duration. Turn on the default-expiration option. If your installed release displays a duration or date control, enter the organization’s approved limit and save the settings. The Server 11.0 documentation describes the public-link default but does not prescribe one universal number of days; choose a value that matches your access policy and the controls shown in your version.
4. Enforce the limit. Check Enforce as maximum expiration date in the public-link section and save. According to ownCloud’s documentation, users can then select an earlier expiration date, while the configured default is the maximum. Enabling only the default is not equivalent to enforcing a maximum.
5. Verify with a test link. Using a test file and a non-sensitive account, create a public link. Confirm that an expiration is prefilled or required, then try selecting a date later than the configured limit. The saved share should not permit a date beyond that ceiling. Also confirm that an earlier date can be saved if your policy allows it. Avoid testing with confidential content or sending a test URL to an outside recipient.

Review links that already exist

Do not assume that changing an administrative default automatically rewrites every public link that was issued earlier. The ownCloud Server guide explains the default and maximum for public-link expiration, but it does not clearly promise that a policy change backdates or shortens every existing share. Treat existing links as a separate review until you confirm your installed version’s behavior.

Open the sharing panel for files or folders that have public links, inspect each link’s expiration, and edit the date or delete the link if it no longer needs to exist. ownCloud supports multiple public links for one item, so check each entry rather than assuming one file has only one link. The public-link documentation describes link settings, including expiration, and the sharing guide explains that a share expires at the end of its specified date and recipients can no longer access it.

If a link is still active beyond the new policy, shorten its expiration or remove it. If your organization has many existing links, use the supported administrative tools and procedures for your exact ownCloud release; avoid directly editing the database because it can bypass application validation and is not a documented configuration step for this task.

Common mistakes to avoid

• Setting a default without enforcing it. A default helps users choose an expiration, but the separate maximum checkbox is what restricts later dates.
• Changing the wrong share policy. Public links are for people outside the ownCloud user list. Local-user, group, and federated shares have separate expiration settings.
• Expecting a universal day count. The official manual does not require one fixed policy period. Your organization must choose and communicate its own limit.
• Confusing a share URL with a private link. A private link points to a file for people who already have permission; it is not the same as a public link. Check that you are editing the public-link entry.
• Assuming expiration is instantaneous at midnight in every viewer’s time zone. ownCloud describes expiry at the end of the selected date; server time is relevant to share expiration. Test with the server’s configured time zone in mind.
• Forgetting that expiration is only one control. It does not add a password, reduce permissions, or disable public link creation. Set password and permission requirements separately if your policy needs them.

Check that the restriction is working

After saving the admin policy, create a test public link and verify three things: the link has an expiration date, an attempted later date cannot exceed the maximum, and a shorter date remains available where expected. Then revisit the test link in the sharing panel to confirm the saved date, and review older public links separately. The OCS Share API documentation also defines the expiration value for a share as a date and says a public link expires at the end of that specified day; this is useful for administrators who verify shares through an approved integration.

Finally, confirm the test link is no longer accessible after its expiration date using an authorized test account, then remove the test share. If a user can still select a date beyond the ceiling, recheck that enforcement was enabled in the public-link section, confirm you edited the correct instance, and consult the documentation for your exact ownCloud release. This gives you a practical check of both the administrator rule and the behavior users see.