You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Nextcloud failing to setup: ActivityNotFoundException: No Activity found to handle Intent { act=android.intent.action.VIEW #14306
I (obviously) have a browser installed on my phone. Chrome is the default browser. (But it also has the Samsung browser)
I have tried (multiple times) to clear cache and clear data, and reinstalled from Play store from scratch.
I open the app and enter my domain here:
I tried both entering as in the screenshot (just the FQDN) as well as including https:// in front of it manually. (Though the header on the text box suggests I don't need to?)
But either way fails the same. (The log that opened this case was from just entering the FQDN without https:// in front of it)
(when manually entering https:// in front of it, the error also shows HTTPS in upper case (on the act=android.intent.action VIEW line). For what that's worth...)
What's weird is that it was working last week when I tried signing up (though it got hung up on the registering the phone in Nextcloud, but that was an issue with my proxy that has since been resolved.)
I can log in to my nextcloud instance just fine from a browser. (Both at home, and here at the office)
changed the title [-]Nextcloud failing to setup through Android app[/-][+]Nextcloud failing to setup: `ActivityNotFoundException: No Activity found to handle Intent { act=android.intent.action.VIEW`[/+]on Jan 6, 2025
@JvdMaat Are you using Android Private spaces or additional profiles or anything like that?
Nothing I'm aware of. Just using a single Chrome/Google profile. No KNOX, nothing else. (I can't find Private Space in my settings. Maybe Samsung blocks that in favor of KNOX?)
Just changed my phone's default browser to Samsung's built-in browser and got the same result.
Also tried a restart of my phone.
I definitely have a default browser. Not sure why that part is failing. I also opened other apps and clicked on URLs within those apps, and they opened up the default browser no problem.
Is this working with another Nextcloud server?
Can you try it with demo1.nextcloud.com (you will not be able to login, but at least to see if your NC url has problems).
demo1 works. So it's something in my docker instance.
I do run it behind swag, with this in the nextcloud.subdomain.conf file:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name nextcloud.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app nextcloud;
set $upstream_port 80;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
proxy_buffering off;
}
}
(Which seems to work fine for accessing it from a webbrowser, as that has no issues. So something the phone app is doing specifically is not supported somehow.)
Snippets from my config.php on the nextcloud side: (If there's anything else that's pertinent, let me know)
The 192.168.9.9 is the IP of my dockerhost. Swag runs in a container on that alongside nextcloud (and nextcloud-redis, the mariadb, etc).
I do see that the Android app is connecting to my nextcloud instance. If I put in a hostname that's not running nextcloud, it gives me a malformed server configuration error.
The docker logs for the nextcloud container do show this when the Android app tries to connect:
And FWIW, here's what the nextcloud container has in the docker logs upon startup:
Conf remoteip disabled.
To activate the new configuration, you need to run:
service apache2 reload
Configuring Redis as session handler
Warning: /var/www/html/config/redis.config.php differs from the latest version of this image at /usr/src/nextcloud/config/redis.config.php
Warning: /var/www/html/config/reverse-proxy.config.php differs from the latest version of this image at /usr/src/nextcloud/config/reverse-proxy.config.php
Warning: /var/www/html/config/s3.config.php differs from the latest version of this image at /usr/src/nextcloud/config/s3.config.php
Warning: /var/www/html/config/smtp.config.php differs from the latest version of this image at /usr/src/nextcloud/config/smtp.config.php
=> Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/before-starting
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.37. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.37. Set the 'ServerName' directive globally to suppress this message
[Tue Jan 07 13:25:51.732483 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00163: Apache/2.4.62 (Debian) PHP/8.2.26 configured -- resuming normal operations
[Tue Jan 07 13:25:51.732547 2025] [core:notice] [pid 1:tid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
172.18.0.26 - admin [07/Jan/2025:13:25:52 -0500] "GET /ocs/v2.php/apps/serverinfo/api/v1/info?format=json&skipUpdate=false&skipApps=false HTTP/1.1" 200 3011 "-" "python-requests/2.32.3"
Are there any other logs on the nextcloud side I could look at?
On an unrelated note, looking at the logs from the admin user (settings/admin/logging), it has this spamming over and over multiple times a minute:
{
"reqId": "kzKoSqfGHI9KbLgFF3ci",
"level": 2,
"time": "2025-01-07T18:38:15+00:00",
"remoteAddr": "172.18.0.26",
"user": "admin",
"app": "no app in context",
"method": "GET",
"url": "/ocs/v2.php/apps/notifications/api/v2/notifications",
"message": "Link of notification is not an absolute URL and does not work in mobile and desktop clients [app: firstrunwizard, subject: apphint-recognize]",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0",
"version": "30.0.4.1",
"data": [],
"id": "677d749d79099"
}
The HTTPS (in caps) here is the intermediate culprit. It's the reason the intent isn't working because Android doesn't accept HTTPS (or any mixed case) when triggering intents.
So where is the HTTPS coming from?
The client gets it from the login field in the form populated by your Nextcloud Server.
Unless there are some overlooked overwrite* config values in place (just in case: please check your real config by using occ config:list system since you're using the image as noted in its docs)... I suspect your reverse proxy is sending along a capitalized protocol your Nextcloud Server.
Yes we can maybe make this more robust by making the protocol lowercase, but doesn't change the fact that somewhere this is happening in your infrastructure unexpectedly.
Looks like the only way this can get through is if overwriteprotocol is set.
Can you check the real config? Keep in mind that Compose variables and whatnot take priority over your main config.php values in Docker. So check occ config:list system.
Bingo...
"overwriteprotocol": "HTTPS",
That's from the occ config:list system command.
And it came from my docker-compose. I do have an OVERWRITEPROTOCOL=HTTPS in there. (next to the other overwrites all in lowercase)
When I get home tonight I'll check my browser history, as I likely copy/pasted that from somewhere, so there's a guide that has that in uppercase out there somewhere. (Or maybe I just entered that in all caps for some reason). But I just added those last week when I setup the SMTP settings as well.
I noticed in the documentation that for the SMTP setup you can specify TLS or SSL, and the documentation for those also puts them in lowercase (ssl/tls) for in the docker compose environment variables. Whereas I put them in my docker compose as uppercase.
(And email works, so there's no issue there. I'm assuming because you just check to see if it's TLS or SSL and don't care about the case).
Maybe a simple converting the OVERWRITEPROTOCOL to lowercase before putting it in the active config.php may fix user issues relating to this.
Activity
tobiasKaminsky commentedon Jan 6, 2025
Thank you for report.
It seems that our app fails to find any app that can open the url.
Do you have any browser installed?
It seems also that you typed "HTTPS", can you retry it with "https"?
JvdMaat commentedon Jan 6, 2025
I (obviously) have a browser installed on my phone. Chrome is the default browser. (But it also has the Samsung browser)

I have tried (multiple times) to clear cache and clear data, and reinstalled from Play store from scratch.
I open the app and enter my domain here:
I tried both entering as in the screenshot (just the FQDN) as well as including https:// in front of it manually. (Though the header on the text box suggests I don't need to?)
But either way fails the same. (The log that opened this case was from just entering the FQDN without https:// in front of it)
(when manually entering https:// in front of it, the error also shows HTTPS in upper case (on the act=android.intent.action VIEW line). For what that's worth...)
What's weird is that it was working last week when I tried signing up (though it got hung up on the registering the phone in Nextcloud, but that was an issue with my proxy that has since been resolved.)
I can log in to my nextcloud instance just fine from a browser. (Both at home, and here at the office)
[-]Nextcloud failing to setup through Android app[/-][+]Nextcloud failing to setup: `ActivityNotFoundException: No Activity found to handle Intent { act=android.intent.action.VIEW`[/+]joshtrichards commentedon Jan 6, 2025
We can probably better handle a browser not being found by wrapping the
startActivity()intryand giving a more informative message:android/app/src/main/java/com/owncloud/android/authentication/AuthenticatorActivity.java
Lines 482 to 486 in 57c02dc
https://developer.android.com/training/basics/intents/sending#no-app-available
Given all the other spots where we call this intent also feels like we could have a nice helper function to take care of it all.
Looks like we have an old-style one here (that we could maybe adapt but needs to be updated):
android/app/src/main/java/com/owncloud/android/utils/DisplayUtils.java
Lines 800 to 805 in 57c02dc
@JvdMaat Are you using Android Private spaces or additional profiles or anything like that?
JvdMaat commentedon Jan 6, 2025
Nothing I'm aware of. Just using a single Chrome/Google profile. No KNOX, nothing else. (I can't find Private Space in my settings. Maybe Samsung blocks that in favor of KNOX?)
Just changed my phone's default browser to Samsung's built-in browser and got the same result.
Also tried a restart of my phone.
I definitely have a default browser. Not sure why that part is failing. I also opened other apps and clicked on URLs within those apps, and they opened up the default browser no problem.
tobiasKaminsky commentedon Jan 7, 2025
Is this working with another Nextcloud server?
Can you try it with demo1.nextcloud.com (you will not be able to login, but at least to see if your NC url has problems).
JvdMaat commentedon Jan 7, 2025
demo1 works. So it's something in my docker instance.
I do run it behind swag, with this in the nextcloud.subdomain.conf file:
(Which seems to work fine for accessing it from a webbrowser, as that has no issues. So something the phone app is doing specifically is not supported somehow.)
Snippets from my config.php on the nextcloud side: (If there's anything else that's pertinent, let me know)
The 192.168.9.9 is the IP of my dockerhost. Swag runs in a container on that alongside nextcloud (and nextcloud-redis, the mariadb, etc).
I do see that the Android app is connecting to my nextcloud instance. If I put in a hostname that's not running nextcloud, it gives me a malformed server configuration error.
The docker logs for the nextcloud container do show this when the Android app tries to connect:
And FWIW, here's what the nextcloud container has in the docker logs upon startup:
Are there any other logs on the nextcloud side I could look at?
On an unrelated note, looking at the logs from the admin user (settings/admin/logging), it has this spamming over and over multiple times a minute:
(And the same for the Icon of notification)
joshtrichards commentedon Jan 7, 2025
The
HTTPS(in caps) here is the intermediate culprit. It's the reason the intent isn't working because Android doesn't acceptHTTPS(or any mixed case) when triggering intents.So where is the
HTTPScoming from?The client gets it from the
loginfield in the form populated by your Nextcloud Server.https://github.com/nextcloud/server/blob/bd9a88bb053d898867664447e8780d713de7d1bd/core/Controller/ClientFlowLoginV2Controller.php#L291
The protocol there is populated by this bit of code:
https://github.com/nextcloud/server/blob/1ed3f03a1b0d6b5cd69993321074dbf3826a7e85/lib/private/AppFramework/Http/Request.php#L619
Unless there are some overlooked
overwrite*config values in place (just in case: please check your real config by usingocc config:list systemsince you're using the image as noted in its docs)... I suspect your reverse proxy is sending along a capitalized protocol your Nextcloud Server.Yes we can maybe make this more robust by making the protocol lowercase, but doesn't change the fact that somewhere this is happening in your infrastructure unexpectedly.
joshtrichards commentedon Jan 7, 2025
Actually I partially take that back. Server already has a safeguard for inappropriate casing from the proxy.
https://github.com/nextcloud/server/blob/1ed3f03a1b0d6b5cd69993321074dbf3826a7e85/lib/private/AppFramework/Http/Request.php#L633-L635
Looks like the only way this can get through is if
overwriteprotocolis set.Can you check the real config? Keep in mind that Compose variables and whatnot take priority over your main
config.phpvalues in Docker. So checkocc config:list system.JvdMaat commentedon Jan 7, 2025
Bingo...
"overwriteprotocol": "HTTPS",
That's from the occ config:list system command.
And it came from my docker-compose. I do have an OVERWRITEPROTOCOL=HTTPS in there. (next to the other overwrites all in lowercase)
When I get home tonight I'll check my browser history, as I likely copy/pasted that from somewhere, so there's a guide that has that in uppercase out there somewhere. (Or maybe I just entered that in all caps for some reason). But I just added those last week when I setup the SMTP settings as well.
But phone app now connects without issue.
tobiasKaminsky commentedon Jan 8, 2025
Glad to hear that it is resolved.
joshtrichards commentedon Jan 9, 2025
I'll try to make this type of configuration matter more apparent via nextcloud/server#50099.
JvdMaat commentedon Jan 9, 2025
I noticed in the documentation that for the SMTP setup you can specify TLS or SSL, and the documentation for those also puts them in lowercase (ssl/tls) for in the docker compose environment variables. Whereas I put them in my docker compose as uppercase.
(And email works, so there's no issue there. I'm assuming because you just check to see if it's TLS or SSL and don't care about the case).
Maybe a simple converting the OVERWRITEPROTOCOL to lowercase before putting it in the active config.php may fix user issues relating to this.
ahmedmdyasin97-web commentedon Aug 28, 2025
wifi password check