Creating a public link wont work while the nextcloud server has "enforce password protection" enabled.
This problem started with version 2.5.3, is still there in 2.6.0 and also in the daily build 2.7.0.5919.
My guess is that https://github.com/nextcloud/desktop/pull/1191 started the problem.
When creating a public link with the desktop client it should ask for a password, if "enforce password protection" enabled on the nextcloud server.
After clicking on the + button the password field will not be shown, the loading animation loops infinitely and no link will be created.
Client version: 2.6.0 and newer
Operating system:
Windows 10 1607 LTSC / Windows 10 1809
OS language: German
Installation path of client:
C:\Program Files (x86)\Nextcloud
[OCC::AccessManager::createRequest 4 "" "https://nextcloud.domain/nextcloud/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json" has X-Request-ID "removed"
[OCC::AbstractNetworkJob::start OCC::OcsShareJob created for "https://nextcloud.domain/nextcloud" + "ocs/v2.php/apps/files_sharing/api/v1/shares" ""
[OCC::WebFlowCredentials::slotFinished request finished
[OCC::AbstractNetworkJob::slotFinished QNetworkReply::ContentAccessDenied "Server hat \"403 Forbidden\" auf \"POST https://nextcloud.domain/nextcloud/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json\" geantwortet" QVariant(int, 403)
[OCC::WebFlowCredentials::stillValid QNetworkReply::ContentAccessDenied
[OCC::WebFlowCredentials::stillValid "Error transferring https://nextcloud.domain/nextcloud/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json - server replied: Forbidden"
I can confirm same behaviour since Version 2.5.3. As we use nextcloud in our company it is a huge issue for us.
Same behaviour with the daily build for MacOS. Tried 2.7.0 from October 4th on macOS 10.14.6 and still can't create a public link.
I can confirm this too. Maybe that's the reason for #1505.
In the iOS Client V2.24.3.1 is this bug fixed. Maybe it's possible to fix this in the desktop client too?
In the latest stable windows client version 2.6.1 the issue still persists.
In the daily build windows client version 2.7.0 the issue still persists.
I can confirm this issue on multible Nexcloud instances. After the client was updated to 2.5.3 or newer and "enforce password protection" is enabled sharing via the client don't work.
Could it be that noone reads the issues anymore? I'm just wondering because the issue was reported a while ago and till now not even a confirm from the team...
In the latest stable windows client version 2.6.2 the issue still persists.
Please solve this issue. Thank you.
The log of client when trying to share is this:
[OCC::AccessManager::createRequest 4 "" "https://miserver.com/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json" has X-Request-ID "8965985d8e-9715-418e-b8da-ddb9ddadfh522221"
[OCC::AbstractNetworkJob::start OCC::OcsShareJob created for "https://miserver.com" + "ocs/v2.php/apps/files_sharing/api/v1/shares" ""
[OCC::WebFlowCredentials::slotFinished request finished
[OCC::AbstractNetworkJob::slotFinished QNetworkReply::ContentAccessDenied "El servidor respondi贸 \"403 Forbidden\" a \"POST https://miserver.com/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json\"" QVariant(int, 403)
[OCC::WebFlowCredentials::stillValid QNetworkReply::ContentAccessDenied
[OCC::WebFlowCredentials::stillValid "Error transferring https://miserver.com/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json - server replied: Forbidden"
With the curl command the answer is correct. Notice the use of -H.
curl -u user:passwd 'https://miserver.com/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json' -H "OCS-APIRequest: true"
{"ocs":{"meta":{"status":"ok","statuscode":200,"message":"OK"},"data":[{"id":"196","share_type":0,"uid_owner":"user","displayname_owner":"UUU","permissions":1 ......
In the daily build windows client version 2.7.0 the issue still persists.
nextcloud-2.7.0.6138-daily-20191226-Release.exe
Please, please , please could anyone of the devs from the Nextcloud Desktop Client take a look at this issue? It鈥榮 a must have to enforce password protection for creating a link. Please, please fix this issue in the Desktop Client as this one is fixed in the mobile clients before ...
Many many thanks in advance...
Most helpful comment
In the latest stable windows client version 2.6.1 the issue still persists.