Another WebDav login Problem... Auth error 401

Server
1

I can't login to my new installation with the client using either LDAP accounts or local logins.

Searching has led me here:

1) Is this still the best resource for this problem?

2) If I tell you all that the oc log shows , in part : "user":"--","app":"PHP","method":"GET", can someone help me shortcut that really long list of subtle problems to check? I think that the "--" means the username is being lost somewhere, but I could be wrong.

3) The log also has a message about "using a fallback implementation of the intl extension. Installing the native one is highly recommended instead." Can someone please confirm that this is actually related to the problem? As it's 'recommended' and not 'fatal error', I don't think it's the cause.

All responses are most welcome, I'm 95% complete with this set up and I only need a little bit extra from the community.

Please?

2

Okay, well I'll work with that link then. Here's my noted in case they help anyone else, because that document is reasonable at pushing people to a desired state, but not very helpful for testing various conditions.

You are using an outdated version of the client (upgrade to the newest version, available here166, and try again)

Nope, latest beta + curl test below fails too.

Rewrite module is not enabled / not configured or not working properly

Apache is doing all sort of rewrites, so it's enabled and working properly. Some info is missing from that page.
1) How do I test that an owncloud-specific rewrite rule is working -- how can I test this dependency?
2) Where is the owncloud rewrite config? What rewrites are needed?

There are no requirements for a rewrite config at https://doc.owncloud.org/server/10.0/admin_manual/installation/source_installation.html, so I'll assume that the working module is all that's needed and move on, but some way to test this would be helpful.

On the server running owncloud, a separate WebDAV module is enabled, and it interferes with owncloud's built-in WebDAV module.

If I run
curl -u name -i -X PROPFIND https://server/mycloud/remote.php/webdav

I get a response that includes WWW-Authenticate: Basic realm="ownCloud" and some oc cookies, so I thinks that's fine there.

You could have some required HTTP verbs disabled

I think the PROPFIND above covers these, because if it was a limited verb I'd get a 405 error not a 401 error.

Your webserver has configured a Basic Auth authentication

It does, but only for other directories, so that's not it, surely?

Your webserver isn't passing your credentials to php in the standard way (You will see a message like "Sabre_DAV_Exception_NotAuthenticated No basic authentication headers were found").

I don't get that error message in the log, I get "You are using a fallback implementation of the intl extension.", and I don't think that's the cause of my problem. Happy to be corrected on this!

You have a security software/module (like SELinux) running

selinuxenabled
echo $?

Prints a 1, so that's not it.

One or more module listen in this146 FAQ is installed / enabled

Nope, I couldn't find any of those setup except Basic Auth, ETags are MTime and Size.

You might be running ownCloud behind a reverse proxy; in that case you should ensure that your proxy is configured to pass WebDAV queries. See this forum thread for the case of the Pound reverse proxy: https://forum.owncloud.org/viewtopic.php?t=4949103

I'm not.

You are using php in cgi mode on CentOS79.

Hmmmmm... How do I check this? The linked post doesn't tell me, so:

https://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/, then....
Server API CGI/FastCGI

Aha. So, OC doens't work with PHP in CGI mode.

Does anyone know why this might be? Can I find more detail on this? Can developers chime in on how to debug this maybe? I have 'debug' => true, in my php config, but I'm not getting any more detail in the log.

I'd rather (get help to) figure out why and change that if possible than to just change the server config, though I accept that it's going to be a more popular view to push the server to a known good/supported config instead.

3

Aha! This is in the response to the curl PROPFIND, not in the log.

The linked page, https://forum.owncloud.org/viewtopic.php?f=3&t=1894#p2448, has patch info for lib/base.php that doesn't really apply to the current version(s).

I can see the clinet is sending a header for Authorization: Basic, how can I see what owncloud is getting from apache?

4

As well as debug true, I also needed "loglevel" => "0", to get anything extra in the logs, but that still doesn't help me.

It seems that lots and lots of people have this problem with a range of applications, not just OC, and there's code at the bottom of lib/base.php that's supposed to deal with this situation, but it's not working in my setup.

Can someone please get in touch and help me see whatever remote.php is seeing? I've setup some other phpinfo style scripts to check against but there's no auth info there, I think because the server isn't "authing" those, and I don't necessarily want to setup a PHP authentication service to try and fix this without at least some interest from the community.

Even if I could just get a way to run code in base.php that would dump output somewhere, that would be a start!

Thanks....

5

Ok I found a (bad) way to do it:

            $foo = phpinfo();
                            throw new \RuntimeException(sprintf($foo));

so now I can do this:
curl -u usernamestring -i -X PROPFIND https://servername/owncloud/remote.php/webdav > myfile

and the string 'usernamestring' doesn't appear anywhere in the file myfile at all.

This is so frustrating! How can I figure out what's going on here?

6

Alright, I got it, moving php from cgi to an apache module gave me this:

"There is no suitable CSPRNG installed on your system"

... so changing the virtualhost entry in httpd.conf from

php_admin_value open_basedir /path/to/own/cloud/

to:

php_admin_value open_basedir /path/to/own/cloud/:/dev/urandom

Fixed that problem, and now it works, and I can login from my phone.

Case closed, hope this helps other people.