Error 401 in iOS App

[Dennis1993]

Expected behaviour

No error message

Actual behaviour

after I starting the App the error 401 is shown. In server log the message "bad login for "274782-23134234-45345435345-123213" " (ldap user) is shown

Steps to reproduce

start the App and login with the ldap account

Reasoning or why should it be changed/implemented?

iOS version

13.3.1

App version

2.25.69

Server configuration

Operating system: Ubuntu 16.04

Web server: Apache 2.4

Database: MySQL 5.7

PHP version: 7.3.14

Nextcloud version: (see Nextcloud admin page) 17.0.3

I read the installation guide again and checked all PHP modules, All ok. Maybe a problem with the App? The error message appiers 1 or 2 seconds and then the files are displayed and I can use it...

[oe73773]

I have same problem and it is reported by multiple user using iOS Application Version 2.25.6.9 .

Server Configuration:

Operating system: "Debian GNU/Linux 10 (buster)"

Web Server: Apache/2.4.38

Database: Ver 15.1 Distrib 10.3.17-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

PHP version: PHP 7.3.11-1~deb10u1

Nextcloud version: 16.0.7

We do not use LDAP

[dimadonskoy]

Same here on last update from 6.02.2020 IOS - 13.3.1 Iphone Xs

Server - Centos 7 Nextcloud 17.0.3

[big-net]

I have the same Problem IOS - 13.3.1 Iphone XR App-Version 2.25.6.9

Server - Debian 9.11 Nextcloud 17.0.3

[r-sherwood]

Same here since the last iOS app update, but just with LDAP accounts.

iOS - 13.3 iphone 8 App-Version 2.25.6.9

Server - centOS 8 nginx php-FPM Nextcloud 18.0.1 RC1

[Fisico]

Same issue with a Nextcloud user and also no file upload possible.

{"reqId":"wdk064ruaGusnkwCFsmj","level":2,"time":"2020-02-09T20:14:43+01:00","remoteAddr":"x.x.x.x","user":"--","app":"core","method":"PROPFIND","url":"/remote.php/webdav","message":"Login failed: 'User' (Remote IP: 'x.x.x.x')","userAgent":"Mozilla/5.0 (iOS) Nextcloud-iOS/2.25.6","version":"17.0.3.1","id":"5e405a23debad"}

IOS 13.3.1 iPhone X App-Version 2.25.6.9

Server- Ubuntu Server 16.04 nginx php-fpm Nextcloud Server 17.0.3

[Pofilo]

Same here: iOS - 13.3 iphone 7 App-Version 2.25.6.9

Server - Debian 10.2 apache Nextcloud 18.0.1 RC1

[DominikWA]

Same problem on my side, with multiple nextcloud instances v16 - v18, on multiple iOS clients with the latest app update.

[D3nisssss]

After update of the iOS client on several iPads, I have the same problem.

• PHP Version : 7.2.24
• mysql Version : 5.7.29
• Ubuntu : 18.04
• Apache

[benschhold]

The users are now case sensitive, when i type in the user like its written in AD it works

[big-net]

Yes that's it, the users are case sensitive now. It works for me.

[blizzz]

Is there anything in then nextcloud.log about the failed auth attempt?

[WillixJ]

Same issue here with Version 14 of NC.

[halloamt]

[Justus Bisser] We have the same Error. Correct case does not help. We also tried QR login that also does not work…

Here are sime lines from our access.log, hope that helps

anon@cloud:/var/log/apache2# tail -f access.log -n100 1.1.1.1 - USERNAME [10/Feb/2020:15:07:58 +0100] "PROPFIND /nextcloud/remote.php/dav/files/02156451-6546545645-45564-465-4650116546/ HTTP/1.1" 207 1374 "-" "Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)" 1.1.1.1 - USERNAME [10/Feb/2020:15:08:05 +0100] "PROPFIND /nextcloud/remote.php/dav/files/02156451-6546545645-45564-465-4650116546/ HTTP/1.1" 207 1375 "-" "Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)" 1.1.1.1 - USERNAME@provider.com [10/Feb/2020:15:08:16 +0100] "GET /nextcloud/ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 2176 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.25.6" 1.1.1.1 - 02156451-6546545645-45564-465-4650116546 [10/Feb/2020:15:08:16 +0100] "REPORT /nextcloud/remote.php/dav/files/USERNAME@provider.com HTTP/1.1" 404 905 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.25.6" 1.1.1.1 - USERNAME@provider.com [10/Feb/2020:15:08:16 +0100] "GET /nextcloud/ocs/v1.php/cloud/capabilities?format=json HTTP/1.1" 200 4413 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.25.6" 1.1.1.1 - 02156451-6546545645-45564-465-4650116546 [10/Feb/2020:15:08:16 +0100] "GET /nextcloud/index.php/avatar/USERNAME@provider.com/128 HTTP/1.1" 404 935 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.25.6" 1.1.1.1 - USERNAME@provider.com [10/Feb/2020:15:08:16 +0100] "SEARCH /nextcloud/remote.php/dav HTTP/1.1" 207 2579 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.25.6" 1.1.1.1 - USERNAME@provider.com [10/Feb/2020:15:08:16 +0100] "GET /nextcloud/ocs/v2.php/apps/files_sharing/api/v1/shares HTTP/1.1" 200 2529 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.25.6" 1.1.1.1 - USERNAME@provider.com [10/Feb/2020:15:08:16 +0100] "GET /nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications?format=json HTTP/1.1" 200 1686 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/2.25.6" 1.1.1.1 - USERNAME [10/Feb/2020:15:08:28 +0100] "PROPFIND /nextcloud/remote.php/dav/files/02156451-6546545645-45564-465-4650116546/ HTTP/1.1" 207 1374 "-" "Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)" 1.1.1.1 - USERNAME [10/Feb/2020:15:08:37 +0100] "PROPFIND /nextcloud/remote.php/dav/files/02156451-6546545645-45564-465-4650116546/ HTTP/1.1" 207 1375 "-" "Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)" 1.1.1.1 - USERNAME [10/Feb/2020:15:08:58 +0100] "PROPFIND /nextcloud/remote.php/dav/files/02156451-6546545645-45564-465-4650116546/ HTTP/1.1" 207 1374 "-" "Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)" 1.1.1.1 - USERNAME [10/Feb/2020:15:09:01 +0100] "GET /nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications?format=json HTTP/1.1" 304 219 "-" "Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)" 1.1.1.1 - USERNAME [10/Feb/2020:15:09:09 +0100] "PROPFIND /nextcloud/remote.php/dav/files/02156451-6546545645-45564-465-4650116546/ HTTP/1.1" 207 1375 "-" "Mozilla/5.0 (Windows) mirall/2.6.2stable-Win64 (build 20191224) (Nextcloud)"

[blizzz]

@halloamt all entries in the access.log are fine, none reports an error related to this issue. Is there anything in the nextcloud.log (in you data directory, or via Admin Settings → Logging)?

@WillixJ Nc 14 reached end of life last summer https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule

[blizzz]

And, do all of you affected login with email address?

[benschhold]

Only user, if i use the users email address there is no problem, if i use the user like its written in AD there is no problem, if you dont use it like that, everything in upper case for example, you get a 401 in apache. This is a nasty bug because the users lock there AD accounts because of this Only in IOS app and in all nextcloud installations (13-18) This issue wasnt present last week

[Volker-K]

Same problem here, after deleting and reinstalling NC app no account can be registered, neither with AD or local account managed by Nextcloud. Accounts that were existing before updating to iOS 13.3.1 may get a 401 when accessing any file.

[git-dd]

getting the same error NC 17.0.3 LDAP + database cached passwords no matter if I type case-sensitive username or not access is possible but the error (screenshots above) pops up every ~3rd time I open a directory with Version 2.25.5 there was no problem

[D3nisssss]

We are using the LDAP username. We are not using the email address. The problem still persist.

The error message on ipad is displayed on the screen a couple of seconds and disapears. The problem looks like a time out error for us.

[herrmannsdorfer]

NC 17.0.3, LDAP login

Related warnings in the log are numerous:

[core] Warning: Login failed: 'my LDAP userId' (Remote IP: 'our gw') PROPFIND /nextcloud/remote.php/webdav from 'our gw IP' at 2020-02-11T11:18:41+00:00

[halloamt]

Funnily the Adroid Client works perfectly well. I cannot look at nextcloud.log at the moment. we tried E-Mail and LDAP username and neither worked. I'll send you some log lines later or tomorrow.

[Quax1507]

Same error here with NC 17.0.3 and 18.0.1RC2

[JoeKun]

I'm encountering the same bug on with Nextcloud for iOS 2.25.6.9, pointed to Nextcloud Server 17.0.2. I use LDAP authentication on my server, and this has worked perfectly fine for several months. Please note that I'm not encountering any issues with either the web interface, or the macOS desktop app.

After enabling debug logs on my server, I found something interesting about the LDAP queries.

When authentication works, I see logs like this:

{
    "reqId":"[redacted]",
    "level":0,
    "time":"2020-02-11T20:03:08+00:00",
    "remoteAddr":"[redacted]",
    "user":"[redactedUID]",
    "app":"user_ldap",
    "method":"PROPFIND",
    "url":"\/remote.php\/dav\/files\/[redactedUID]\/",
    "message":"initializing paged search for  Filter (&(objectClass=inetOrgPerson)(ou:dn:=users)(supportedApplication=nextcloud)(mail=[redactedEmailAddress])) base Array\n(\n    [0] => ou=directory\n)\n attr Array\n(\n    [0] => entryuuid\n    [1] => nsuniqueid\n    [2] => objectguid\n    [3] => guid\n    [4] => ipauniqueid\n    [5] => dn\n    [6] => uid\n    [7] => samaccountname\n    [8] => memberof\n    [9] => mail\n    [10] => cn\n    [11] => jpegphoto\n    [12] => thumbnailphoto\n)\n limit 500 offset 0",
    "userAgent":"Mozilla\/5.0 (Macintosh) mirall\/2.6.2stable (build 20191224) (Nextcloud)",
    "version":"17.0.2.1"
}

But when authentication fails, I see logs like this instead:

{
    "reqId":"[redacted]",
    "level":0,
    "time":"2020-02-11T19:58:39+00:00",
    "remoteAddr":"[redacted]",
    "user":"--",
    "app":"user_ldap",
    "method":"PROPFIND",
    "url":"\/remote.php\/webdav",
    "message":"initializing paged search for  Filter (&(objectClass=inetOrgPerson)(ou:dn:=users)(supportedApplication=nextcloud)(mail=[redactedUID])) base Array\n(\n    [0] => ou=directory\n)\n attr Array\n(\n    [0] => entryuuid\n    [1] => nsuniqueid\n    [2] => objectguid\n    [3] => guid\n    [4] => ipauniqueid\n    [5] => dn\n    [6] => uid\n    [7] => samaccountname\n    [8] => memberof\n    [9] => mail\n    [10] => cn\n    [11] => jpegphoto\n    [12] => thumbnailphoto\n)\n limit 500 offset 0",
    "userAgent":"Mozilla\/5.0 (iOS) Nextcloud-iOS\/2.25.6",
    "version":"17.0.2.1"
}

I took the liberty to pretty print the JSON logs, as well as redacting some private information. Namely, I redacted my email address with [redactedEmailAddress] (and that's what I normally use in the Username or email text field of the login form), and I redacted the internal ID Nextcloud uses for that account with [redactedUID] (I'm referring to the hexadecimal ID with the following format ab0cd123-e4f5-6789-0a12-3b4c5d67e890).

For reference, in the "Login Attributes" tab of the LDAP settings of my Nextcloud instance, I entered the following LDAP query:

(&(objectClass=inetOrgPerson)(ou:dn:=users)(supportedApplication=nextcloud)(mail=%uid))

So what's clearly wrong in the failed LDAP authentication case here is that the %uid format specifier of this query was replaced with the generated UID for my account (which, again, looks like ab0cd123-e4f5-6789-0a12-3b4c5d67e890), whereas it should have been replaced with my email address.

Another interesting difference between these two logs is that only the log for the authentication failure shows:

    "user":"--",

Does this help track down the root cause of these authentication issues?

[blizzz]

@JoeKun the interesting part is in the LDAP filter. When authenticated, the lookup went via mail=[redactedEmailAddress, which totally makes sense. In the failing case it was compared with an uid mail=[redactedUID], which expectedly does not yield the correct user.

[JoeKun]

@blizzz I'm far from being an expert of the underpinnings of Nextcloud, but I'm not sure this makes a lot of sense to me. Isn't this LDAP query meant to be executed before and in order to get the authentication result?

What I'm getting at is this: if we don't even run the correct LDAP query to actually authenticate the user, then what chance do we have of successfully authenticating the user?

Please let me know if that assumption of mine was incorrect, and if in fact this "Login Attributes" LDAP query is meant to be used after the authentication process has completed.

[blizzz]

@JoeKun we on the server side can only pass in the query what we receive as login name. So it might be, that the app mixes up login name and user id… but right now we do not know where and why this could be. Also, til now we could not reproduce this behaviour.

[marinofaggiana]

Hi all, who can create a test account for me for help we to find the problem ?

[D3nisssss]

Hi, I have just send test account information in your mail.

[benschhold]

Could it be a webdav bug? remote.php/dav/files/user1/ gives not found remote.php/dav/files/User1/ is found

[Volker-K]

There's another error we've found when an iOS device was migrated from iOS 12 to 13 and Nextcloud is accessed via Files app. In that case it seems to be a WebDAV connection made by iOS. In case the user had to change his password (as forced in lot of LDAP/AD environmehts) NC App worked fine but the Files app didn't unless it was deleted and installed new. I've gut two iOS devices. The iPad had this error, too, unless I did a hard reset and installed all apps from scratch. After that I couldn't reproduce this error any more.

The current error can be reproduced on my iPhone (migrated from iOS 12.x to 13.3.1 in steps) but not on the iPad (migrated from iOS 12 to 13.3, hard reset, migrated to 13.3.1). The same QR-code that does not work on the iPhone works on the iPad. The same network, the same NC Instance, the same user account, the same iOS and NC App versions, the only difference I can see is the hard reset after migrating from iOS 12 to 13.

[bnavigator]

@Volker-K please report that as separate issues and keep this one for the ldap related login errors.

[iNoels]

Same here: iOS - 13.3.1 iPhone X App-Version 2.25.7.0

Server - Ubuntu 18.04 LTS Apache 2.4.29 PHP 7.2.24 Nextcloud 18.0.0

Same Server with local User and no SMB = no Problem Maybe it's related to the LDAP or SMB access

[D3nisssss]

We are using LDAP Same as iNoels for me :

• without SMB folder = OK

• with SMB folder = NOT OK

[Quax1507]

We use SMB folders, too. I can confirm, it is not working.

[patrickober]

We do not user SMB folders, although IOS app is not working with LDAP/AD anymore, as @benschhold described we have to use case sensitive usernames in IOS APP to get it working.

[Dennis1993]

No SMB here ☺️

[Volker-K]

@bnavigator We're using LDAP/AD auth. The latest App version works with both my devices, at the device of a coworker it doesn'n. I'll try to catch some log records tomorrow to see which errors I will find.

[kuhlmannmarkus]

Same for me! Its annoying! It works as expected on my Android phone, so I suspect the issue to be within the IOS app.

[bnavigator]

No SMB and all lowercase uids here. It's clearly as described by @JoeKun in https://github.com/nextcloud/ios/issues/1147#issuecomment-584838480: The iOS app sends the generated UUID instead of the entered username (or e-mail in his case).

[marinofaggiana]

This error is under investigation, please stop and wait a solution.

thanks

[marinofaggiana]

Fixed, soon available, version 2.25.8 (TestFlight & Apple Store)

[QJarhead]

After update to version 2.25.8 IOS App, we got the Error 404, while the ios tries to access the url:

https://xxxxxxx/ remote.php/dav/files/xxxx@xxxx.com

[marinofaggiana]

@QJarhead verify that exists the /files/xxxx@xxxx.com in your server because it's used for the searchrequest (where userID == xxxx@xxxx.com)

[QJarhead]

Hey @marinofaggiana , currently all folders in /var/www/html/data/ are created as the UID of the Users. 001AD1BE-C2ED-4709-8679-AF4178ED32A1 37E92B40-BF59-4CD8-8FE3-16FABA8AD97D.....

[benschhold]

Issue is still present, users are still case sensitive

[marinofaggiana]

Issue is still present, users are still case sensitive

where it is written that it must be Case insensitive?

[bcutter]

First check: red box is gone. Not using LDAP. Need to check logs when having access to the server. Endpoint (App v2.25.8) looks good after few minutes testing.

[DominikWA]

This issue is still present for our iOS users, too.

[benschhold]

Issue is still present, users are still case sensitive

where it is written that it must be Case insensitive?

nowhere but it would be strange if only apple users are have to do so

[Dennis1993]

After the update the red box is gone. Now the next error message appears 😂