Shared URL will change

I had saved the document file in the folder set in the group folder Nextcloud application.
I got the share URL of that file and informed my colleagues. It is not a direct link.

Example of sharing url:

I tried to access the file using that link for the first time in half a month. However, the shared URL was invalidated and I could not open the file. The display error sentence is “Is it deleted or has it expired?”

The file exists and I did not set any settings when I set up file sharing. All off state. Of course I have not set an expiration date. Why was the share URL invalidated?

I issued a share URL again today, and that address was different from the previous one. Is it normal for file sharing URLs to change as time passes?

This time it’s still under my control so it’s not fatal. The link broke after I handed the share URL to the other party. Is there a repair method in this case? Link the current file to the old published share URL link.

Nextcloud 15.0.2 / CentOS 7.6 / PHP 7.3 / MariaDB 10.2.21 / Nginx 1.14.1

Will the shared URL be changed when the first owner of the data (sharing setter) saves / updates the data?
It seems that it will not change at least for the past few days. Or is the shared URL changed like a bug?

I abandoned the data for a while and then changed the file name, the shared URL was changed. Is this normal?

No, share URLs don’t change on their own, nor does NC “invalidates” them out of nowhere. The most likely reason for such a behaviour would be an issue with NC file cache table, where an entry pointed to the wrong file object on the disk and when the other object’s share URL got revoked, or the other object got deleted, the share URL had been deleted alongside.

From that end, NC’s filecache table is utterly important to be in perfect shape/order.

1 Like

When at least the problem occurred, I never intentionally removed the shared URL in all data.

I repeated the act of neglecting the file from that, changing the file name and obtaining the shared URL several times. But it did not reproduce. Is coincidence high?

Last time I was not myself. Today I was facing change of shared URL. At that time I did not record the error even if I looked at the log. Is this a problem with Group Folder application? An error has occurred everyday in Cron with Group Folder. This seems to be reported to GitHub.

Currently I am investigating the change of shared URL in normal directory. It has not occurred at least in this 6 hours.
The function of Group Folder is important. How can I prevent unintended change of shared URLs?

To be able to judge any of this stuff, one would need to know exactly who did what to those files and when. I do believe that re-sharing of files in a group folder is allowed and thus you might have no control over who grants and revokes shares from those files, which would indeed invalidate previous share links. However, the share link to the groupfolder itself shouldn’t change.

Groupfolder is inherently a collaborative tool and I can easily picture different people creating/revoking share links to the same file/folder inside the groupfolder.

The file I tried today was the file I made for the first time. The directory was also unknown. I contacted the user who was logged in at that time. There are only two people in that time zone. They then mounted on Windows 10 then were editing the files owned by themselves. They do not access the directory set by Group Folder. I saw setting monitoring, including myself active user was 3 people in the axis within 5 minutes.

If it changes itself, it is clearly a bug. I happened to me as well as I deleted a share by accident and recreated it what changed the link.

Regardless of whether I release the shared URL or re-enable the shared URL, will the same shared URL always be issued at all times?

If a share link gets revoked, aka the object gets unshared, re-sharing the object will create a different link.

There seems to be a problem with the Group Folder application at this time.

The Group Folder has been updated to 2.0.3 and seems to have solved this problem.