Link expiration date non changeable - Ubuntu

[RomeroVerde]

Expected behaviour

It should be possible to set a link expiration date either by writing or with arrows (it was working perfectly before)

Actual behaviour

Once a link is shared and set expiration date is selected, the current date is set. It is not possible to change the date neither by typing or with the arrows.
After clicking in share, it says expiration date is in the past error message.

Steps to reproduce

1.Nautilus right click
2.Nextcloud > Shared Options
3. Click on "..." > Set expiration Date
4. The error is there

Client configuration

Client version: Desktop 3.4.0 (Ubuntu)

Operating system: Ubuntu

OS language: English

Qt version used by client package (Linux only, see also Settings dialog):

Client package (From Nextcloud or distro) (Linux only):
Ubuntu

[torbatschow]

Same here (same specs), only with file manager nemo (and the respective plugin, package nemo-nextcloud). I am not sure, though, whether this is a plugin issue or a Nextcloud one.

[mrdaftpunk]

I'm seeing this on Kubuntu (using the Dolphin file manager) and also on Windows 10 since installing 3.4.1 today.

[TibiTaebi]

Same problem with my installation on Windows 10 with 3.4.1.
And by the way let us also pick a date by opening a calendar.

[github-actions]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[G6ofUNSATO]

Also affected: Nextcloud Desktop-Client
Version 3.4.2 (Windows). on Windows 10 / Server 2012 R2
please fix this isssue

Sideaffects with Serversettings --> configuring "default expiration date: 7 days"
File --> Sharingoptions
GUI will appear with todays date
Date is not changeable, but also no error appears

[s-h-f-p]

Hi,
problem still exists (Windows 10, since Desktop-Client-Version 3.4.0, tried every version in between)
Last version working as intended is 3.3.6.
Seems not to be a server problem as all connections to differnet servers are either working (with 3.3.6) or not working (with >=3.4.0).

[G6ofUNSATO]

Still no Update here...
Even setting an expiration date via web will not reflect to the client.

[gtntdev]

Same here...
Windows Client: 3.4.2
Ubuntu Server: 22.2.4.3
(NC hosted on docker behind traefik)
This issue appears on all Clients and all NC instances hosted on multible different servers.
It worked a few months ago, can't say when exactly.
If you need more information please let me know.
Setting the expiration date and time through the WEB UI works fine.

[OliverPifferi]

Same effect here on macOS 12.2.1 "Monterey" with Client 3.4.3 installed, same with the Windows-client on a separate system with Nextcloud 23.0.2 and NGINX as Webserver backend.

Ubuntu Server 20.04.4
NC hosted via Nextcloud AIO 0.60

The web interface works fine here, too - but on the client side, the date cannot be changed nor deleted, also the spinning wheel keeps showing up.

[kotta-hu]

Same problem Here:

macOS Big Sur

Nextcloud client version: 3.4.3 (latest)

[s-h-f-p]

I can confirm this: expiration still not working on Win10 with Nextcloud-Client 3.4.3...

[s-h-f-p]

When trying to set link expiration date, this one is logged in my access.log (http status 404):

[18/Mar/2022:09:39:26 +0100] "PUT /ocs/v2.php/apps/files_sharing/api/v1/shares/672?format=json HTTP/1.1" 404 120 "-" "Mozilla/5.0 (Windows) mirall/3.4.3stable-Win64 (build 20220225) (Nextcloud, windows-10.0.19042 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

and just 1 second later (http status 200):
[18/Mar/2022:09:39:27 +0100] "PUT /ocs/v2.php/apps/files_sharing/api/v1/shares/672?format=json HTTP/1.1" 200 485 "-" "Mozilla/5.0 (Windows) mirall/3.4.3stable-Win64 (build 20220225) (Nextcloud, windows-10.0.19042 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

Desktop-Client-Log (set hostname to host.domain.tld):
2022-03-18 09:27:03:245 [ warning nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-9389\client-building\desktop\src\libsync\abstractnetworkjob.cpp:224 ]: QNetworkReply::ContentNotFoundError "Server hat \"404 Not Found\" auf \"PUT https://host.domain.tld/ocs/v2.php/apps/files_sharing/api/v1/shares/670?format=json\" geantwortet" QVariant(int, 404)
2022-03-18 09:27:03:245 [ warning nextcloud.sync.credentials.webflow C:\Users\sysadmin\AppData\Local\Temp\2\windows-9389\client-building\desktop\src\gui\creds\webflowcredentials.cpp:227 ]: QNetworkReply::ContentNotFoundError
2022-03-18 09:27:03:245 [ warning nextcloud.sync.credentials.webflow C:\Users\sysadmin\AppData\Local\Temp\2\windows-9389\client-building\desktop\src\gui\creds\webflowcredentials.cpp:228 ]: "Error transferring https://host.domain.tld/ocs/v2.php/apps/files_sharing/api/v1/shares/670?format=json - server replied: Not Found"
2022-03-18 09:27:03:245 [ warning nextcloud.gui.sharing.ocs C:\Users\sysadmin\AppData\Local\Temp\2\windows-9389\client-building\desktop\src\gui\ocsjob.cpp:128 ]: Reply to "PUT" QUrl("https://host.domain.tld/ocs/v2.php/apps/files_sharing/api/v1/shares/670") (QPair("expireDate","2022-03-18")) has unexpected status code: 404 "{\"ocs\":{\"meta\":{\"status\":\"failure\",\"statuscode\":404,\"message\":\"Das Ablaufdatum liegt in der Vergangenheit.\"},\"data\":[]}}"

[biva]

For information, also reproduce on Windows 11 / Client 3.4.4 / Server 23.0.3

[walec51]

this is such a basic feature not available for 4 months now...

I wish I could go back to ownCloud...

Windows 10, client 3.4.4

[tlueder]

This is still happening on 3.5 RC2 for mac

[github-actions]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[mrdaftpunk]

This is still an ongoing problem with the 3.5.0 client on both Windows 10 21H2 and Ubuntu 20.04, the link expiration feature does not work and hasn't since ~3.3.4. In addition, there is garbled overlapping text beneath the file name:

Please could somebody look at this? It has been 6 months now with no movement.

[OliverPifferi]

Can confirm this with the combination of Nextcloud 24.0.0 and Client 3.5.0git (build 10063) with macOS 12.3.1. Also, the UI seem to have similar problems with overlapping text as @mrdaftpunk reported - there still seems some work to do although the client itself works good and is stable so far.

[TibiTaebi]

This bug doesn't seem to get any attention from the nextcloud development team. You would think that something marked as bug would be assigned to a milestone sooner or later. It has been 5 months and still no response. I understand that it's not a serious bug and that there is a workaround (I'm still using version 3.0.3), so it has low priority.
Nevertheless, such bugs should be fixed in a useful period of time.
Should this bug be posted somewhere else?

[claucambra]

Hey all,

We have a fix for this in the pipelines now. The issue was caused by the client setting a maximum date for the date-setting field in the link share based on the server's setting for maximum days until expiry. The maximum date for the date field is calculated as the current date plus the number of maximum days until expiry.

In cases where the maximum days until expiry is not set on the server, the value returned acquired by the client would be 0. Since the minimum valid day until expiry is at least a day after the share link is created, the date-setting box would have its maximum value set to today+0, which the server would not accept. This was made worse by the minimum value of the date field being set to today+1, making the date field completely unusable.

Our fix now changes this behaviour to only set a maximum date for the date field where the value acquired from the server by the client for the maximum days until expiry is larger than 0. This fix should be part of the next bugfix relase 3.5.1.

Thanks to all for reporting!

[labor4]

Edit: Note this is Macos.

@claucambra
Is this in 3.5.1?
Because in 3.5.1 Macos I still cannot change the date.
That is, which values I can enter are heavily filtered by the GUI.

Example:

I will be able to set "06.07.22", or "07.07.22", but not "09.07.22".
Also if I set the date to "06.07.22" in client, and change it to "31.07.22" on server,
then the client will mask the (visible) value to "08.07.22" again, and overwrite this to server if saved...

Note: today is 24.06.22, and "08.07.22" is 2 weeks into the future.
2 weeks are 14 days, which is my server's default (non-enforced) expiration value.
My guess: Some insect in the code interprets this as a maximum possible value, whereas the server does not mean that.
I believe the meaning is to allow higher values, which is congruent to server GUI behaviour.

A note of a possible misunderstanding:
I could not find find a setting for "maximum days until expiry" in server config.php or GUI Settings.
I can only find "default expiration date", as per the screenshot below.

I believe this to be the correct bug and therefore re-open.

[claucambra]

@labor4 Unfortunately I could not reproduce your issue, unenforced expiration dates did not trigger a ceiling to the share expiration dates in the client for me. Could you share desktop client logs? What server version are you running?

[claucambra]

Closing due to lack of info, but please feel free to reopen if you can reproduce the issue and provide logs/more info

[labor4]

Closing due to lack of info, but please feel free to reopen if you can reproduce the issue and provide logs/more info

sorry for that. too busy here, unexpectedly.
I'll do it properly when I have time.
cheers!

[FelixBuehler]

I too still have this issue in 3.6.0.

@labor4 exactly describes the problem, that the "default" timespan is somehow interpreted as maximum allowed time in the desktop app (Win 10x64).

Don't know what else to provide, since my logs don't show any error or info.

[claucambra]

@labor4 @FelixBuehler I was able to reproduce and have issued a fix with #4982 thanks for bringing it up!