server
server copied to clipboard
Error when creating share
I am using nextcloud snap but the the people on the snap-respository told me that such issues affect the server-repository.
I have been getting this error for a few days now:
When I want to share a folder with another person on my nextcloud there is this error:
Translation: "Error when creating share"
How to reproduce this error: Click on the sharing-icon on the folder and select another cloud-user. Then the error message appears. Despite the error the user gets access and the user is shown in the sharing-list after refreshing the page.
Tested on version 18.0.4 This has only started occuring recently (snap updates itself)
I get this in v19.0.0 and v19.0.1 (upgraded from v18 to v19, worked fine in v18).
Created new file using web interface, clicked share.
Error message appears: Error creating the share
.
File manager shows (for a short while) that the file is shared, and activity log shows share link was created (and expired), the share details don't show link.
The log:
[no app in context] Error: Exception: Call to a member function format() on bool at <<closure>>
0. /private/var/www/nextcloud19/lib/private/AppFramework/App.php line 137
OC\AppFramework\Http\Dispatcher->dispatch(OCA\Files_Sharin ... {}, "createShare")
1. /private/var/www/nextcloud19/lib/private/AppFramework/Routing/RouteActionHandler.php line 47
OC\AppFramework\App::main("OCA\\Files_Shar ... r", "createShare", OC\AppFramework\ ... {}, {_route: "ocs.fi ... "})
2. <<closure>>
OC\AppFramework\Routing\RouteActionHandler->__invoke({_route: "ocs.fi ... "})
3. /private/var/www/nextcloud19/lib/private/Route/Router.php line 297
call_user_func(OC\AppFramework\ ... {}, {_route: "ocs.fi ... "})
4. /private/var/www/nextcloud19/ocs/v1.php line 88
OC\Route\Router->match("/ocsapp/apps/fi ... s")
5. /private/var/www/nextcloud19/ocs/v2.php line 24
require_once("/private/var/ww ... p")
POST /ocs/v2.php/apps/files_sharing/api/v1/shares
Issue only occur after enabling :
Settings > Sharing > Allow Users to share via link > Set default expiration date for link shares
To be sure, the summary is: sharing with expiration date does not work. when I set expiration date (either default or for specific share): I get error message and can not share. When I share without expiration date everything is fine.
What further triage is needed? Happy to help.
To be sure, the summary is: sharing with expiration date does not work. when I set expiration date (either default or for specific share): I get error message and can not share. When I share without expiration date everything is fine.
What further triage is needed? Happy to help.
I have added the linked issue above with more details from the browsers JavaScript log.
For me the message also appears when Settings > Sharing > Allow Users to share via link > Set default expiration date for link shares
is not enabled
Pretty sure the server error is the indication of what the root cause is. It seems the expire date is a boolean instead of string, which causes the format() of that string to fail.
I also get the error in Nextcloud 19.4. I share it with users and groups, not as a link. There is no entry in the error logs. The checkbox with expiration date i not checked, but doubt it's relevant as I not share it via link.
do you have a default expiration date set? Settings > Sharing Either for "Set default expiration date for shares" or "Set default expiration date for link shares"
I tried any combination, but no change. I tried setting the share on a folder. It works when sharing a file.
so do you get ther error when both settings are disabled? Could be a different issue then.
What do you see in the server log?
I get the error no matter what this setting is for either: All disabled, one of them enabled and all of them disabled, can't share the folder. Server log doesn't show anything about the error to share.
Everyone here, please give us your browser logs As well as potential nextcloud.log php errors
Hello! I will need your browser console log to investigate this issue. Open your console, reload your page and/or do the action leading to this issue and copy/paste the log in this thread.
How to access your browser console (Click to expand)
Chrome
- Press either CTRL + SHIFT + J to open the “console” tab of the Developer Tools.
- Alternative method:
- Press either CTRL + SHIFT + I or F12 to open the Developer Tools.
- Click the “console” tab.
Safari
- Press CMD + ALT + I to open the Web Inspector.
- See Chrome’s step 2. (Chrome and Safari have pretty much identical dev tools.)
IE9
- Press F12 to open the developer tools.
- Click the “console” tab.
Firefox
- Press CTRL + SHIFT + K to open the Web console (COMMAND + SHIFT + K on Macs).
- or, if Firebug is installed (recommended):
- Press F12 to open Firebug.
- Click on the “console” tab.
Opera
- Press CTRL + SHIFT + I to open Dragonfly.
- Click on the “console” tab.
No errors in nextcloud.log. Console gives this error:
Error while creating share Error: Request failed with status code 403
Stack trace:
e.exports@https://
I will need a screenshot of your network requests.
Before you do anything, still on the development tools, there is a tab called network
. Click on it and then the xhr filter. Do your action and screenshot the network log like this:
Please also click on the failing 403 request and copy/paste the response content here
Here's the screenshot with the response, this error response explains the problem. A shame the error is not displayed elsewhere:
So because there is another share in that folder it's not allowed to share the parent.
@Skalli what path are you trying to share? It state that you are sharing a folder that contains a mount point (another share)
cc @rullzer @nickvergessen we cannot share a folder that contains a share? https://github.com/nextcloud/server/blob/de7026f6e4662ff42e0a3c12021a3cee25c5d91f/lib/private/Share20/Manager.php#L678
Yeah, it was a folder, one subfolder had a share. I wasn't aware of that limit and the very generic error message was not helpful. I moved the shared subfolder to a different location and then adding the share worked. So my proposal would be to give a more meaningful error message for this use case.
Yes @skjnldsv otherwise you could create loops:
- User A shares A1 to user B
- User B puts A1 in the folder B1
- User B shares B1 to user A
- User A puts B1 in folder A1
It would break your sync client, the file scan and everything else. So having a received share inside a shared item is not possible.
Let's just improve the wording then and block sharing ? Can we preemptively check if a folder contains one?
Just wanted to chime in.
- Nextcloud-server 19.0.4-1 (deb10)
This is quite odd since the response, as can be seen below contains much more than one would expect. Almost as if debugging was enabled in Circles maybe? This error only happens for me when trying to share with a circle. Sharing with a group or with an individual user works fine.
Request:
Request URL: https://cloud.tentwentyfour.lu/ocs/v2.php/apps/files_sharing/api/v1/shares
Request Method: POST
Status Code: 200
Remote Address: 31.22.124.149:443
Request payload:
{path: "/Fun", permissions: 31, shareType: 7, shareWith: "8e5e0a8787fd9f"}
path: "/Fun"
permissions: 31
shareType: 7
shareWith: "8e5e0a8787fd9f"
Response:
* Expire in 0 ms for 6 (transfer 0x55f769811140)
* Expire in 30000 ms for 8 (transfer 0x55f769811140)
* Expire in 150000 ms for 2 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 1 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Expire in 0 ms for 1 (transfer 0x55f769811140)
* Trying 31.22.124.149...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55f769811140)
* Connected to cloud.tentwentyfour.lu (31.22.124.149) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=cloud.tentwentyfour.lu
* start date: Oct 30 16:17:48 2020 GMT
* expire date: Jan 28 16:17:48 2021 GMT
* subjectAltName: host "cloud.tentwentyfour.lu" matched cert's "cloud.tentwentyfour.lu"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> POST /apps/circles/v1/payload HTTP/1.1
Host: cloud.tentwentyfour.lu
Content-Type: application/x-www-form-urlencoded
User-Agent: Nextcloud Server Crawler
Content-Length: 64
* upload completely sent off: 64 out of 64 bytes
< HTTP/1.1 200 OK
< Server: nginx
< Date: Sun, 08 Nov 2020 16:09:57 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 6
< Connection: keep-alive
< Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< X-Download-Options: noopen
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: none
< X-XSS-Protection: 1; mode=block
< Set-Cookie: ************************************; path=/; secure; HttpOnly; SameSite=Lax
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Set-Cookie: oc_sessionPassphrase=**********************************************************************; path=/; secure; HttpOnly; SameSite=Lax
< Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-***********************************='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< Set-Cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< Set-Cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< Vary: Accept-Encoding
< Strict-Transport-Security: max-age=15768000
< Strict-Transport-Security: max-age=15768000
<
* Connection #0 to host cloud.tentwentyfour.lu left intact
{"ocs":{"meta":{"status":"ok","statuscode":200,"message":"OK"},"data":{"id":"211","share_type":7,"uid_owner":"08ece906-d7b8-1035-9c8d-97c38bc36d8d","displayname_owner":"David Raison","permissions":31,"can_edit":true,"can_delete":true,"stime":1604851797,"parent":null,"expiration":null,"token":null,"uid_file_owner":"08ece906-d7b8-1035-9c8d-97c38bc36d8d","note":"","label":"","displayname_file_owner":"David Raison","path":"\/Fun","item_type":"folder","mimetype":"httpd\/unix-directory","storage_id":"home::08ece906-d7b8-1035-9c8d-97c38bc36d8d","storage":3,"item_source":77346,"file_source":77346,"file_parent":312,"file_target":"\/Fun","share_with_displayname":"BuCo (Closed circle, David Raison)","share_with_avatar":"https:\/\/cloud.tentwentyfour.lu\/apps\/circles\/img\/closed.svg","share_with":"8e5e0a8787fd9","mail_send":0,"hide_download":0}}}
@kwisatz your share looks fine though (core response 200 and creation accepted). So might be fixed by https://github.com/nextcloud/server/pull/23981 too
Yes, the share was indeed created. But the front-end application of course can't handle a response body like that.
You mean a response body like
{
"ocs": {
"meta": {
"status": "ok",
"statuscode": 200,
"message": "OK"
},
"data": {
"id": "211",
"share_type": 7,
"uid_owner": "08ece906-d7b8-1035-9c8d-97c38bc36d8d",
"displayname_owner": "David Raison",
"permissions": 31,
"can_edit": true,
"can_delete": true,
"stime": 1604851797,
"parent": null,
"expiration": null,
"token": null,
"uid_file_owner": "08ece906-d7b8-1035-9c8d-97c38bc36d8d",
"note": "",
"label": "",
"displayname_file_owner": "David Raison",
"path": "/Fun",
"item_type": "folder",
"mimetype": "httpd/unix-directory",
"storage_id": "home::08ece906-d7b8-1035-9c8d-97c38bc36d8d",
"storage": 3,
"item_source": 77346,
"file_source": 77346,
"file_parent": 312,
"file_target": "/Fun",
"share_with_displayname": "BuCo (Closed circle, David Raison)",
"share_with_avatar": "https://cloud.tentwentyfour.lu/apps/circles/img/closed.svg",
"share_with": "8e5e0a8787fd9",
"mail_send": 0,
"hide_download": 0
}
}
}
Looks good to me :thinking:
Yes, if that were the response body, that'd be fine. But what I listed above as Response
is what I received from the back-end.
So the response body wrapped inside an entire HTTP Response object, including the headers, the network info, etc.
I have a different behavior today.
Request:
Request URL: https://cloud.tentwentyfour.lu/ocs/v2.php/apps/files_sharing/api/v1/shares
Request Method: POST
Status Code: 404
{path: "/buco", permissions: 31, shareType: 7, shareWith: "8e5e0a8787fd9f"}
Response
<?xml version="1.0"?>
<ocs>
<meta>
<status>failure</status>
<statuscode>404</statuscode>
<message>Invalid query, please check the syntax. API specifications are here: http://www.freedesktop.org/wiki/Specifications/open-collaboration-services.
</message>
</meta>
<data/>
</ocs>
Yes, if that were the response body, that'd be fine. But what I listed above as
Response
is what I received from the back-end. So the response body wrapped inside an entire HTTP Response object, including the headers, the network info, etc.
That definitely looks like a setup issue then. No response should contains this. It looks like a curl extended response. How did you setup nextcloud? Also might be good to open a new issue, yours doesn't seems to have anything related to this one
I will need a screenshot of your network requests. Before you do anything, still on the development tools, there is a tab called
network
. Click on it and then the xhr filter. Do your action and screenshot the network log like this: ...Please also click on the failing 403 request and copy/paste the response content here
details of what I see (saw) in the server log: https://github.com/nextcloud/server/issues/21120#issuecomment-660126451
The issue is still the same, even though currently I don't see that error anymore in the server log, and the client does not show an error message. To reproduce for me:
- create a file using the browser client (e.g. test.md)
- share the file without expiration date - everything is fine
- wait ± 1 minute and reload the file list page - everything is fine: file shows sharing icon
- modify sharing: add expiration date
- wait ± 1 minute and reload the file list page - everything is fine: file shows sharing icon
- click on the sharing icon of the file, sidebar appears
- in sidebar sharing icon has disappeared and file is no longer being shared, after reloading the file list share icon has disappeared
In the server log I see this one dozens of times in last week or so (not directly linked to the sharing issue)
Error: Undefined offset: 3 at /private/var/www/cloud/lib/private/legacy/OC_Helper.php#548
/private/var/www/cloud/lib/private/legacy/OC_Helper.php - line 548:
OC\Log\ErrorHandler::onError(8, "Undefined offset: 3", "/private/va ... p", 548, { path: "/", ... }})
/private/var/www/cloud/apps/files/lib/Helper.php - line 51:
OC_Helper::getStorageInfo("/")
/private/var/www/cloud/apps/files/lib/Controller/AjaxController.php - line 47:
OCA\Files\Helper::buildFileStorageStatistics("/")
/private/var/www/cloud/lib/private/AppFramework/Http/Dispatcher.php - line 169:
OCA\Files\Controller\AjaxController->getStorageStats("/")
/private/var/www/cloud/lib/private/AppFramework/Http/Dispatcher.php - line 100:
OC\AppFramework\Http\Dispatcher->executeController(OCA\Files\Co ... {}, "getStorageStats")
/private/var/www/cloud/lib/private/AppFramework/App.php - line 152:
OC\AppFramework\Http\Dispatcher->dispatch(OCA\Files\Co ... {}, "getStorageStats")
/private/var/www/cloud/lib/private/Route/Router.php - line 308:
OC\AppFramework\App::main("OCA\\Files\ ... r", "getStorageStats", OC\AppFramew ... {}, { action: nu ... "})
/private/var/www/cloud/lib/base.php - line 1009:
OC\Route\Router->match("/apps/files ... p")
/private/var/www/cloud/index.php - line 37:
OC::handleRequest()
The devtools show an (I think) normal PUT for the file, including the expiration as string:
ocs: {meta: {status: "ok", statuscode: 200, message: "OK"},…}
data: {id: "79", share_type: 3, uid_owner: "...", displayname_owner: "...",…}
can_delete: true
can_edit: true
displayname_file_owner: "..."
displayname_owner: "..."
**expiration: "2020-11-30 00:00:00"**
file_parent: 7
file_source: 217786
file_target: "/test.md"
hide_download: 0
id: "79"
item_source: 217786
item_type: "file"
label: ""
mail_send: 0
mimetype: "text/markdown"
note: ""
parent: null
password: null
path: "/kanweg.md"
permissions: 17
send_password_by_talk: false
share_type: 3
share_with: null
share_with_displayname: "(Shared link)"
stime: 1604933224
storage: 2
storage_id: "home::..."
token: "123456789"
uid_file_owner: "..."
uid_owner: "..."
url: "https://mycloud/s/123456789"
meta: {status: "ok", statuscode: 200, message: "OK"}
when reloading I see a couple of requests:
Including a 404 error inside the XML of the PROPFIND call (statuscode 207):
https://mycloud/remote.php/dav/systemtags-relations/files/217786
https://mycloud/ocs/v2.php/collaboration/resources/file/217786?format=json
:
{ocs: {meta: {status: "ok", statuscode: 200, message: "OK"}, data: []}}
ocs: {meta: {status: "ok", statuscode: 200, message: "OK"}, data: []}
data: []
meta: {status: "ok", statuscode: 200, message: "OK"}
message: "OK"
status: "ok"
statuscode: 200
Immediately followed by a 404 for:
https://mycloud/ocs/v2.php/apps/spreed/api/v1/file/217786
{ocs: {,…}}
ocs: {,…}
data: []
meta: {status: "failure", statuscode: 404, message: "File is not shared, or shared but not with the user"}
message: "File is not shared, or shared but not with the user"
status: "failure"
statuscode: 404
This problem takes place also on a new installation 19.04
it does not work
Settings > Sharing > Allow Users to share via link > Set default expiration date for link shares
@finalls can you screenshot or copy the failed request response like the comment above please ? :)
Immediately followed by a 404 for:
https://mycloud/ocs/v2.php/apps/spreed/api/v1/file/217786
{ocs: {,…}} ocs: {,…} data: [] meta: {status: "failure", statuscode: 404, message: "File is not shared, or shared but not with the user"} message: "File is not shared, or shared but not with the user" status: "failure" statuscode: 404
{ocs: {meta: {status: "failure", statuscode: 403,…}, data: []}}
ocs: {meta: {status: "failure", statuscode: 403,…}, data: []}
data: []
meta: {status: "failure", statuscode: 403,…}
message: "Address in mailbox given [Share [email protected]] does not comply with RFC 2822, 3.6.2."
status: "failure"
statuscode: 403
I changed my email, the error disappeared. Thanks you.
I get the following error. Same problem as original poster, I can not share a newly created folder in the root directory with a group, although there are lots of previously shared folders there. Please let me know if I should share more information with you. This is Nextcloud 19.0.4 on Ubuntu 18.04.5 LTS