server
server copied to clipboard
nextcloud
[Bug]: Share links not working
⚠️ This issue respects the following points: ⚠️
- [X] This is a bug, not a question or a configuration/webserver/proxy issue.
- [X] This issue is not already reported on Github (I've searched it).
- [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- [X] Nextcloud Server is running on 64bit capable CPU, PHP and OS.
- [X] I agree to follow Nextcloud's Code of Conduct.
Bug description
I'm getting a BasicAuth prompt if I want to open a public shared folder
Steps to reproduce
- Create share link
- Give it to anonymous user
- Open the link
Expected behavior
Access to shared folder ist granted
Installation method
Community Manual installation with Archive
Nextcloud Server version
26
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 22.2.3 to 23.0.1)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- [X] Default user-backend (database)
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
Configuration report
{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"uploadportal.14a-it.de"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "26.0.2.1",
"overwrite.cli.url": "https:\/\/uploadportal.14a-it.de",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"default_phone_region": "DE",
"memcache.local": "\\OC\\Memcache\\APCu",
"mail_smtpmode": "smtp",
"mail_sendmailmode": "smtp",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtpauthtype": "LOGIN",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpsecure": "tls",
"mail_smtpauth": 1,
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"maintenance": false,
"theme": "",
"loglevel": 2,
"ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
"mail_smtpport": "587",
"updater.secret": "***REMOVED SENSITIVE VALUE***",
"htaccess.RewriteBase": "\/"
}
}
List of activated Apps
Enabled:
- activity: 2.18.0
- circles: 26.0.0
- cloud_federation_api: 1.9.0
- comments: 1.16.0
- contactsinteraction: 1.7.0
- dashboard: 7.6.0
- dav: 1.25.0
- federatedfilesharing: 1.16.0
- federation: 1.16.0
- files: 1.21.1
- files_pdfviewer: 2.7.0
- files_rightclick: 1.5.0
- files_sharing: 1.18.0
- files_trashbin: 1.16.0
- files_versions: 1.19.1
- firstrunwizard: 2.15.0
- logreader: 2.11.0
- lookup_server_connector: 1.14.0
- nextcloud_announcements: 1.15.0
- notifications: 2.14.0
- oauth2: 1.14.0
- password_policy: 1.16.0
- photos: 2.2.0
- privacy: 1.10.0
- provisioning_api: 1.16.0
- recommendations: 1.5.0
- related_resources: 1.1.0-alpha1
- serverinfo: 1.16.0
- settings: 1.8.0
- sharebymail: 1.16.0
- spreed: 16.0.4
- support: 1.9.0
- survey_client: 1.14.0
- systemtags: 1.16.0
- text: 3.7.2
- theming: 2.1.1
- twofactor_backupcodes: 1.15.0
- updatenotification: 1.16.0
- user_ldap: 1.16.0
- user_status: 1.6.0
- viewer: 1.10.0
- weather_status: 1.6.0
- workflowengine: 2.8.0
Disabled:
- admin_audit: 1.16.0
- bruteforcesettings: 2.6.0
- encryption: 2.14.0
- files_external: 1.18.0
- suspicious_login: 4.4.0
- twofactor_totp: 8.0.0
Nextcloud Signing status
No errors have been found.
Nextcloud Logs
-
Additional info
There is no error in the Config files. It seems that the request is executed correctly but the BasicAuth window appears.
I cannot reproduce this.
Is this a new installation or was this a behavior change you experienced after a recent upgrade?
Your report says you're using NGINX. Can you provide your config?
From the looks of your screenshot, it looks like you're getting access (based on the background) but then also getting a Basic Auth request after gaining apparent access? Is that correct? If so, can you take a look at your browser console and look under the Network section to see which URL request is actually triggering the basic auth pop-up?
It is difficult to say if the BasicAuth request appears after the access, because the content loads a long time. If I put a README.md into the folder, it shows to content of the screenshot. If I put a image into the folder for example, then the content stays white.
I took the config from here (Method 1) : https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html
server {
root /var/www/html/nextcloud;
# Add index.php to the list if you are using PHP
index index.php index.html index.htm index.nginx-debian.html;
server_name XXXX;
server_tokens off;
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate /etc/ssl/certs/XXX.pem;
ssl_certificate_key /etc/ssl/private/XXX.key;
# HSTS settings
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" always;
# set max upload size and increase upload timeout:
client_max_body_size 512M;
client_body_timeout 300s;
fastcgi_buffers 64 4K;
# Logging
error_log /var/log/nginx/uploadportal.error.log;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# Pagespeed is not supported by Nextcloud, so if your server is built
# with the `ngx_pagespeed` module, uncomment this line to disable it.
#pagespeed off;
# The settings allows you to optimize the HTTP2 bandwitdth.
# See https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
# for tunning hints
client_body_buffer_size 512k;
# HTTP response headers borrowed from Nextcloud `.htaccess`
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "noindex,nofollow" always;
add_header X-XSS-Protection "1; mode=block" always;
# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;
# Specify how to handle directories -- specifying `/index.php$request_uri`
# here as the fallback means that Nginx always exhibits the desired behaviour
# when a client requests a path that corresponds to a directory that exists
# on the server. In particular, if that directory contains an index.php file,
# that file is correctly served; if it doesn't, then the request is passed to
# the front-end controller. This consistent behaviour means that we don't need
# to specify custom rules for certain paths (e.g. images and other assets,
# `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
# `try_files $uri $uri/ /index.php$request_uri`
# always provides the desired behaviour.
index index.php index.html /index.php$request_uri;
# Rule borrowed from `.htaccess` to handle Microsoft DAV clients
location = / {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /remote.php/webdav/$is_args$args;
}
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The rules in this block are an adaptation of the rules
# in `.htaccess` that concern `/.well-known`.
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
location /.well-known/pki-validation { try_files $uri $uri/ =404; }
# Let Nextcloud's API for `/.well-known` URIs handle all other
# requests by passing them to the front-end controller.
return 301 /index.php$request_uri;
}
# Rules borrowed from `.htaccess` to hide certain paths from clients
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }
# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
# to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
# Required for legacy support
rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty urls
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_max_temp_file_size 0;
}
location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463";
access_log off; # Optional: Don't log access to assets
location ~ \.wasm$ {
default_type application/wasm;
}
}
location ~ \.woff2?$ {
try_files $uri /index.php$request_uri;
expires 7d; # Cache-Control policy borrowed from `.htaccess`
access_log off; # Optional: Don't log access to assets
}
# Rule borrowed from `.htaccess`
location /remote {
return 301 /remote.php$request_uri;
}
location / {
try_files $uri $uri/ /index.php$request_uri;
}
} server { if ($host = XXX.de) { return 301 https://$host$request_uri; }
listen 80;
listen [::]:80;
server_name uploadportal.14a-it.de;
return 404;
server_tokens off;
}
PS: Forgot to answer your question about the update.
NC25 was a fresh install with this issue, I updated to NC26 to ensure the latest version is used.
Can you also do this part:
If so, can you take a look at your browser console and look under the Network section to see which URL request is actually triggering the basic auth pop-up?
We need to nail down which request seems to be triggering this.
While you're at it, please take a look at your server-side logs when you trigger this situation and report back the entries from:
- your nextcloud logs
- your nginx logs
We have the same problem with some directories since we upgraded to 26.0.x which is quite annoying because external sharing is sometimes not working anymore.
The logs don't have much errors, but there's a NoUserException thats flooding the logs.
[activity] Fehler: OC\User\NoUserException: Backends provided no user object at <<closure>>
0. <<closure>>
OC\Files\Node\Root->getUserFolder()
1. /data/nextcloud/site/lib/private/Files/Node/LazyFolder.php line 72
call_user_func_array()
2. /data/nextcloud/site/lib/private/Files/Node/LazyRoot.php line 40
OC\Files\Node\LazyFolder->__call()
3. /data/nextcloud/site/apps/approval/lib/Activity/ApprovalProvider.php line 125
OC\Files\Node\LazyRoot->getUserFolder()
4. /data/nextcloud/site/apps/activity/lib/MailQueueHandler.php line 468
OCA\Approval\Activity\ApprovalProvider->parse()
5. /data/nextcloud/site/apps/activity/lib/MailQueueHandler.php line 368
OCA\Activity\MailQueueHandler->parseEvent()
6. /data/nextcloud/site/apps/activity/lib/MailQueueHandler.php line 165
OCA\Activity\MailQueueHandler->sendEmailToUser()
7. /data/nextcloud/site/apps/activity/lib/BackgroundJob/EmailNotification.php line 60
OCA\Activity\MailQueueHandler->sendEmails()
8. /data/nextcloud/site/lib/private/BackgroundJob/Job.php line 54
OCA\Activity\BackgroundJob\EmailNotification->run()
9. /data/nextcloud/site/lib/private/BackgroundJob/TimedJob.php line 60
OC\BackgroundJob\Job->execute()
10. /data/nextcloud/site/cron.php line 152
OC\BackgroundJob\TimedJob->execute()
at 2023-06-16T18:15:01+00:00
Don't know if it's related or helps pinning it down.
PPS: I should have read more carefully. Share links won't work with our instance; but we don't have the issue that a BasicAuth Request appears. We just get a "Page not Found"-Error even though the share exists. Shall I enter a new bug report?
I played a bit with link sharing. In most folders – personal or group folders – files can be shared as expected. The groupfolder in which sharing doesn't work, and to which I have access, was also shared with Deck. Beside the fact that sharing doesn't work there's also an error concerning related resources:
Whats different with this folder is that it's not only a groupfolder I have access to, but it's also shared via Deck with me. A colleague added this folder as attachment and it got added as an extra share (which in the case of groupfolders is highly annoying, because one can't which group folder this folder is or to which groupfolders those files belong) and now not only shows in the groupfolder but also as subfolder of /Deck. Maybe some problem with circularity while sharing?
This is the view of the sidebar of the containing folder:
Neither error.log from nginx nor nextcloud.log provide an entry if the url is called
May be this a similuar issue:
Nextcloud 26.0.4 (Nextcloud Hub 4) PHP 8.1.7 Web server: Apache Database engine version: MariaDB
- I did create a public share with password protection (read/write).
- I did create/use "Threema Safe" to use this public share
- Threema Safe over this public share is working
But there are errors into the nextcloud.log:
[files] Fehler: OC\User\NoUserException: Backends provided no user object at <
- <
> OC\Files\Node\Root->getUserFolder() - /var/www/html/nextcloud/lib/private/Files/Node/LazyFolder.php line 73 call_user_func_array()
- /var/www/html/nextcloud/lib/private/Files/Node/LazyRoot.php line 40 OC\Files\Node\LazyFolder->__call()
- /var/www/html/nextcloud/apps/files_versions/lib/Listener/FileEventsListener.php line 357 OC\Files\Node\LazyRoot->getUserFolder()
- /var/www/html/nextcloud/apps/files_versions/lib/Listener/FileEventsListener.php line 209 OCA\Files_Versions\Listener\FileEventsListener->getPathForNode()
- /var/www/html/nextcloud/apps/files_versions/lib/Listener/FileEventsListener.php line 107 OCA\Files_Versions\Listener\FileEventsListener->write_hook()
- /var/www/html/nextcloud/lib/private/EventDispatcher/ServiceEventListener.php line 86 OCA\Files_Versions\Listener\FileEventsListener->handle()
- /var/www/html/nextcloud/3rdparty/symfony/event-dispatcher/EventDispatcher.php line 251 OC\EventDispatcher\ServiceEventListener->__invoke()
- /var/www/html/nextcloud/3rdparty/symfony/event-dispatcher/EventDispatcher.php line 73 Symfony\Component\EventDispatcher\EventDispatcher->callListeners()
- /var/www/html/nextcloud/lib/private/EventDispatcher/EventDispatcher.php line 87 Symfony\Component\EventDispatcher\EventDispatcher->dispatch()
- /var/www/html/nextcloud/lib/private/EventDispatcher/EventDispatcher.php line 99 OC\EventDispatcher\EventDispatcher->dispatch()
- /var/www/html/nextcloud/lib/private/Files/Node/HookConnector.php line 112 OC\EventDispatcher\EventDispatcher->dispatchTyped()
- /var/www/html/nextcloud/lib/private/legacy/OC_Hook.php line 105 OC\Files\Node\HookConnector->write()
- /var/www/html/nextcloud/apps/dav/lib/Connector/Sabre/File.php line 449 OC_Hook::emit()
- /var/www/html/nextcloud/apps/dav/lib/Connector/Sabre/File.php line 323 OCA\DAV\Connector\Sabre\File->emitPreHooks()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 1137 OCA\DAV\Connector\Sabre\File->put()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php line 492 Sabre\DAV\Server->updateFile("*** sensitive parameters replaced ***")
- /var/www/html/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php line 89 Sabre\DAV\CorePlugin->httpPut()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 472 Sabre\DAV\Server->emit()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 253 Sabre\DAV\Server->invokeMethod()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 321 Sabre\DAV\Server->start()
- /var/www/html/nextcloud/apps/dav/appinfo/v1/publicwebdav.php line 123 Sabre\DAV\Server->exec()
- /var/www/html/nextcloud/public.php line 81 require_once("/var/www/html/n ... p")
PUT /public.php/webdav/backups/xxxxxxxxx
[files] Fehler: OC\User\NoUserException: Backends provided no user object at <
- <
> OC\Files\Node\Root->getUserFolder() - /var/www/html/nextcloud/lib/private/Files/Node/LazyFolder.php line 73 call_user_func_array()
- /var/www/html/nextcloud/lib/private/Files/Node/LazyRoot.php line 40 OC\Files\Node\LazyFolder->__call()
- /var/www/html/nextcloud/apps/files_versions/lib/Listener/FileEventsListener.php line 357 OC\Files\Node\LazyRoot->getUserFolder()
- /var/www/html/nextcloud/apps/files_versions/lib/Listener/FileEventsListener.php line 283 OCA\Files_Versions\Listener\FileEventsListener->getPathForNode()
- /var/www/html/nextcloud/apps/files_versions/lib/Listener/FileEventsListener.php line 119 OCA\Files_Versions\Listener\FileEventsListener->remove_hook()
- /var/www/html/nextcloud/lib/private/EventDispatcher/ServiceEventListener.php line 86 OCA\Files_Versions\Listener\FileEventsListener->handle()
- /var/www/html/nextcloud/3rdparty/symfony/event-dispatcher/EventDispatcher.php line 251 OC\EventDispatcher\ServiceEventListener->__invoke()
- /var/www/html/nextcloud/3rdparty/symfony/event-dispatcher/EventDispatcher.php line 73 Symfony\Component\EventDispatcher\EventDispatcher->callListeners()
- /var/www/html/nextcloud/lib/private/EventDispatcher/EventDispatcher.php line 87 Symfony\Component\EventDispatcher\EventDispatcher->dispatch()
- /var/www/html/nextcloud/lib/private/EventDispatcher/EventDispatcher.php line 99 OC\EventDispatcher\EventDispatcher->dispatch()
- /var/www/html/nextcloud/lib/private/Files/Node/HookConnector.php line 159 OC\EventDispatcher\EventDispatcher->dispatchTyped()
- /var/www/html/nextcloud/lib/private/legacy/OC_Hook.php line 105 OC\Files\Node\HookConnector->postDelete()
- /var/www/html/nextcloud/lib/private/Files/View.php line 1295 OC_Hook::emit()
- /var/www/html/nextcloud/lib/private/Files/View.php line 1223 OC\Files\View->runHooks()
- /var/www/html/nextcloud/lib/private/Files/View.php line 729 OC\Files\View->basicOperation()
- /var/www/html/nextcloud/apps/dav/lib/Connector/Sabre/File.php line 536 OC\Files\View->unlink()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Tree.php line 179 OCA\DAV\Connector\Sabre\File->delete()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php line 281 Sabre\DAV\Tree->delete()
- /var/www/html/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php line 89 Sabre\DAV\CorePlugin->httpDelete()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 472 Sabre\DAV\Server->emit()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 253 Sabre\DAV\Server->invokeMethod()
- /var/www/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 321 Sabre\DAV\Server->start()
- /var/www/html/nextcloud/apps/dav/appinfo/v1/publicwebdav.php line 123 Sabre\DAV\Server->exec()
- /var/www/html/nextcloud/public.php line 81 require_once("/var/www/html/n ... p")
DELETE /public.php/webdav/backups/xxxxxxxxxxxxx
Also it seems the public webdav shares are trying to do stuff on the root dir of ncdatadir and directory structure: /files_trashbin/versions do not exist there.
(/files_trashbin/versions do exist only on user base path):
[core] Fehler: unable to rename, destination directory is not writable : /ncdatadir/files_trashbin/versions
DELETE /public.php/webdav/backups
@szaimen This problem persists with NC 27.0.1.
We can reproduce this error like this:
When trying to share a file that is in an groupfolder that have been shared in it's entirety by another user with a deck board; a later created link by a different user who shares from the original groupfolder won't work anymore. The link is created, but a "not found" error displayed when the link is used. When trying to give those new (not working) shares edit rights from the menu in the original groupfolder an error is displayed, that the user don't have sufficient rights:
In the /Deck-Folder it is displayed that the link was shared without rights to reshare it:
This seems to prevent reshares even from users who have full rights to the original groupfolder.
When the share to the deck is remove, the link works again as expected.
@lars-becker - Since the original poster isn't getting these errors can you please move your reports to their own issue? It's making it challenging to work the original reporter's issue. Plus then you can provide your own configuration report/etc - which may be crucial to isolating your situation. :)
@Githopp192 - Same to you. Though your situation could have something to do with @lars-becker's matter at least. However, neither are part of what this Issue is about. Thanks! :)
Since the original poster isn't getting these errors can you please move your reports to their own issue?
Understood. Filed it within the deck app (nextcloud/deck#5048); because the problem we have clearly has to do with the deck integration.
As I cannot reproduce the original issue anymore, I will close this ticket. If this is still happening please make sure to upgrade to the latest version. After that, feel free to reopen.
