Sabre dav exception unknown error while seeking content

Same issue happening to me since the upgrade to 25.
The desktop client is completely unresponsive and spins one core at 100%.

The nextcloud error log produces the following output in the process:

{
  "reqId":"Y3pIdxoRRdu92Hg4N4cABAAAAK0",
  "level":3,
  "time":"2022-11-20T15:32:17+00:00",
  "remoteAddr":"my_ip",
  "user":"me",
  "app":"webdav",
  "method":"POST",
  "url":"/remote.php/dav/bulk",
  "message":"Unknown error while seeking content",
  "userAgent":"Mozilla/5.0 (Windows) mirall/3.4.1stable-Win64 (build 20211221) (Nextcloud, windows-10.0.22623 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
  "version":"25.0.1.1",
  "exception":{
    "Exception":"Sabre\DAV\Exception",
    "Message":"Unknown error while seeking content",
    "Code":500,
    "Trace":[
      {
        "file":"/var/www/nextcloud/htdocs/apps/dav/lib/BulkUpload/MultipartRequestParser.php",
        "line":129,
        "function":"isAt",
        "class":"OCA\DAV\BulkUpload\MultipartRequestParser",
        "type":"->"
      },
      {
        "file":"/var/www/nextcloud/htdocs/apps/dav/lib/BulkUpload/BulkUploadPlugin.php",
        "line":71,
        "function":"isAtLastBoundary",
        "class":"OCA\DAV\BulkUpload\MultipartRequestParser",
        "type":"->"
      },
      {
        "file":"/var/www/nextcloud/htdocs/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
        "line":89,
        "function":"httpPost",
        "class":"OCA\DAV\BulkUpload\BulkUploadPlugin",
        "type":"->"
      },
      {
        "file":"/var/www/nextcloud/htdocs/3rdparty/sabre/dav/lib/DAV/Server.php",
        "line":472,
        "function":"emit",
        "class":"Sabre\DAV\Server",
        "type":"->"
      },
      {
        "file":"/var/www/nextcloud/htdocs/3rdparty/sabre/dav/lib/DAV/Server.php",
        "line":253,
        "function":"invokeMethod",
        "class":"Sabre\DAV\Server",
        "type":"->"
      },
      {
        "file":"/var/www/nextcloud/htdocs/3rdparty/sabre/dav/lib/DAV/Server.php",
        "line":321,
        "function":"start",
        "class":"Sabre\DAV\Server",
        "type":"->"
      },
      {
        "file":"/var/www/nextcloud/htdocs/apps/dav/lib/Server.php",
        "line":360,
        "function":"exec",
        "class":"Sabre\DAV\Server",
        "type":"->"
      },
      {
        "file":"/var/www/nextcloud/htdocs/apps/dav/appinfo/v2/remote.php",
        "line":35,
        "function":"exec",
        "class":"OCA\DAV\Server",
        "type":"->"
      },
      {
        "file":"/var/www/nextcloud/htdocs/remote.php",
        "line":171,
        "args":[
          "/var/www/nextcloud/htdocs/apps/dav/appinfo/v2/remote.php"
        ],
        "function":"require_once"
      }
    ],
    "File":"/var/www/nextcloud/htdocs/apps/dav/lib/BulkUpload/MultipartRequestParser.php",
    "Line":111,
    "message":"Unknown error while seeking content",
    "exception":{
      
    },
    "CustomMessage":"Unknown error while seeking content"
  }
}

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I’ve searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud’s Code of Conduct

Bug description

After upgrading the server to NC 25 stable (25.0.0.18, to be exact), the desktop client (3.6.1 on openSUSE Tumbleweed) does no longer sync from the client to the server. Instead, the client totally freezes, while using 100% CPU load.

It turned out that the bulk upload feature is in error. As a workaround, I turned off bulk upload in the server’s config.php file by adding the following line:

'bulkupload.enabled' => false,

Steps to reproduce

See the description above.

Expected behavior

The client should never freeze, even if the server is behaving incorrectly. Ideally, the client should support bulk upload. As the very minimum – for example, if the origin error is on the server side –, it should fall back to normal upload.

Which files are affected by this bug

–

Operating system

Linux

Which version of the operating system you are running.

openSUSE Tumbleweed

Package

Distro package manager

Nextcloud Server version

25.0.0.18

Nextcloud Desktop Client version

3.6.1

Is this bug present after an update or on a fresh install?

Fresh desktop client install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO — SAML
• Other

Nextcloud Server logs

{
   "app" : "webdav",
   "exception" : {
      "Code" : 500,
      "CustomMessage" : "Unknown error while seeking content",
      "Exception" : "Sabre\DAV\Exception",
      "File" : "/data/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php",
      "Line" : 111,
      "Message" : "Unknown error while seeking content",
      "Trace" : [
         {
            "class" : "OCA\DAV\BulkUpload\MultipartRequestParser",
            "file" : "/data/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php",
            "function" : "isAt",
            "line" : 129,
            "type" : "->"
         },
         {
            "class" : "OCA\DAV\BulkUpload\MultipartRequestParser",
            "file" : "/data/nextcloud/apps/dav/lib/BulkUpload/BulkUploadPlugin.php",
            "function" : "isAtLastBoundary",
            "line" : 71,
            "type" : "->"
         },
         {
            "class" : "OCA\DAV\BulkUpload\BulkUploadPlugin",
            "file" : "/data/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
            "function" : "httpPost",
            "line" : 89,
            "type" : "->"
         },
         {
            "class" : "Sabre\DAV\Server",
            "file" : "/data/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
            "function" : "emit",
            "line" : 472,
            "type" : "->"
         },
         {
            "class" : "Sabre\DAV\Server",
            "file" : "/data/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
            "function" : "invokeMethod",
            "line" : 253,
            "type" : "->"
         },
         {
            "class" : "Sabre\DAV\Server",
            "file" : "/data/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
            "function" : "start",
            "line" : 321,
            "type" : "->"
         },
         {
            "class" : "Sabre\DAV\Server",
            "file" : "/data/nextcloud/apps/dav/lib/Server.php",
            "function" : "exec",
            "line" : 360,
            "type" : "->"
         },
         {
            "class" : "OCA\DAV\Server",
            "file" : "/data/nextcloud/apps/dav/appinfo/v2/remote.php",
            "function" : "exec",
            "line" : 35,
            "type" : "->"
         },
         {
            "args" : [
               "/data/nextcloud/apps/dav/appinfo/v2/remote.php"
            ],
            "file" : "/data/nextcloud/remote.php",
            "function" : "require_once",
            "line" : 167
         }
      ],
      "exception" : {},
      "message" : "Unknown error while seeking content"
   },
   "level" : 3,
   "message" : "Unknown error while seeking content",
   "method" : "POST",
   "remoteAddr" : "*****",
   "reqId" : "Qrxj5bFNAAPoYgTYGy9B",
   "time" : "2022-10-25T13:43:09+00:00",
   "url" : "/cloud/remote.php/dav/bulk",
   "user" : "*****",
   "userAgent" : "Mozilla/5.0 (Linux) mirall/3.6.1git (Nextcloud, opensuse-tumbleweed-6.0.2-1-default ClientArchitecture: x86_64 OsArchitecture: x86_64)",
   "version" : "25.0.0.18"
}

Additional info

Under “Is this bug present after an update or on a fresh install?” I had to select something, although I did not update the client.

Fatal: SabreDAVExceptionBadRequest #6924

Steps to reproduce

Expected behaviour

Actual behaviour

I got dozens of Fatal errors.
many of these: SabreDAVExceptionBadRequest: expected filesize 35840 got 16384
some of these: OCADAVConnectorSabreExceptionFileLocked: «file_XXXX.xlsx» is locked

Fata error: SabreDAVExceptionBadRequest: expected filesize 100340 got 16384

General server configuration

Operating system: Linux nextcloud.systemsnavigator.com 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64

Web server: Apache/2.4.18 (Ubuntu) (apache2handler)

Database: pgsql PostgreSQL 9.5.9 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1

16.04.4) 5.4.0 20160609, 64-bit

PHP version: 7.0.22-0ubuntu0.16.04.1

Nextcloud configuration

Nextcloud version: 12.0.3 — 12.0.3.3

Updated from an older Nextcloud/ownCloud or fresh install:
fresh install. By Daniel from Techandme

Where did you install Nextcloud from:
fresh install. By Daniel from Techandme

Are you using external storage, if yes which one: files_external is disabled

Are you using encryption: no

Are you using an external user-backend, if yes which one: LDAP

Content of config/config.php available on request

Client configuration

Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0

Operating system: YOUR ANSWER HERE

Nextcloud log (data/nextcloud.log)

The text was updated successfully, but these errors were encountered:

Источник

SabreDAVExceptionBadRequest: expected filesize 1024000 got 552960 #1450

Steps to reproduce

1. Take a photo (AutoUpload turned on)
2. Check the log

Expected behavior

Actual behavior

Since I upgraded to 2.0.0RC4 I see this behavior. I can’t say exactly which version that triggered it, but it happens like every time (not investigated further) I take a photo that gets AutoUploaded.

Using Android 7.1.2 on a Nexus 5x + Huawei P10 (don’t know Android version but I think it’s 7.0)

See log for more info.

General server configuration

Operating system: Linux techandme.se 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64

Web server: Apache/2.4.18 (Ubuntu) (apache2handler)

Database: pgsql PostgreSQL 9.6.4 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1

16.04.4) 5.4.0 20160609, 64-bit

PHP version: 7.0.22-0ubuntu0.16.04.1

Nextcloud configuration

Nextcloud version: 12.0.2 — 12.0.2.0

Updated from an older Nextcloud/ownCloud or fresh install: Updated since back in the ownCloud days (5.0 I think it was hehe)

Where did you install Nextcloud from: Nextcloud VM

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: NO
(LDAP/ActiveDirectory/Webdav/. )

Client configuration

Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.78 Chrome/60.0.3112.78 Safari/537.36

Operating system: Ubuntu 17.10 (Budgie)

The text was updated successfully, but these errors were encountered:

@enoch85 are you uploading files from external storage (sd card) or internal?

Also, are the files ok after being uploaded?

@mario The files are automatically uploaded from the Camera Roll with AutoUpload from the internal storage. And yes, the files are OK after upload.

EDIT: No more .thumbnail for example.

Spams my log pretty much:

Just tested dev 20170818 and it doesn’t happen on my Nexus 5. Seems to be the P10 only.

postponing to post-2.0.0 then 🙂

Or it got fixed with soon-to-be-released RC6. We’ll never know xD

Yeah, probably. @enoch85 would you mind providing an update to this issue for RC6 whenever it will be released? 🙂

Seems like the error is gone in RC6, need to confirm a few more days before I can say certain. But initial tests didn’t produce this error.

Forgot to put this on my todo-list and forgot about checking actually. Sorry.

I checked now and I’m sad to say, it’s still there.

Not as frequent as in the passed though.

Did you check if upload gets stopped/paused during the upload? Because this would imply that not all data got uploaded which is strange if the file works, like you mentioned?

I can do some more tests tonight. I work like 12 hour days now, it’s crazy. One full-time job plus Tech and Me and Nextcloud = no spare time plus no sleep.

@enoch85 that’s awesome, I appreciate it very much!

OK, tested to take like 5 pictures in a row on both 4G and WiFi, no errors on RC6. Let’s close this one.

BAM

I think to experience the same issue with Auto uploads failing.

• Nextcloud Android app 3.1.0
• Nextcloud 13.0.2

SabreDAVExceptionBadRequest: expected filesize 1024000 got 765952

I am seeing this behaviour as well. Using the official and up-to-date nextcloud app from the F-Droid store, I cannot upload any files bigger than 1MB. Smaller files do not raise any issues and downloading works for files of any size (tested with 50kB-100MB).
When utilizing the webinterface from my personal computer, I can upload and download files of up to 100MB (bigger files not tested)

SabreDAVExceptionBadRequest: expected filesize 1024000 got 466944

@nextcloud/server-triage does this mean that a wrong chunk was sent? Or that something during transmission broke?

It means CONTENT_LENGTH does not match the number of bytes we wrote after receiving the chunk

Can we figure out when and/or why this is happening?
For me it sounds like a transmission problem?

So, I found the reason for my issues although I don’t understand the strange behaviour. I have NetGuard installed which creates a VPN and blocks undesired internet access by apps. What I did is to use a whitelist for apps (which obviously included the nextcloud app) and I did not see any issues that I would have thought of to be firewall related. But: When I disable NetGuard, the upload from the nextcloud app works fine for images >1MB. I did not test bigger files but I expect the issue to be resolved for me — more or less.

What I don’t understand is, why the upload is working for smaller files with the enabled firewall while it fails for bigger files and where the downloads don’t seem to care about the enabled firewall for any filesize. Also, I would guess that there is some kind of data transmission (so not all data is being blocked) as the logs state «expected x byte/got y byte», where x>y>0. Calendar/Contact Sync via DavDroid have been working with the enabled firewall as well. So, I dont know what makes the difference between chunked and non-chunked file uploads from the perspective of a firewall.

So, my next question is: Does anybody have a clue what I need to whitelist in my firewall in order to have a proper functioning of the nextcloud app with an enabled firewall on my mobile?

@Thorbinjho I’ve encountered the same problem, and in circumstances similar to yours: I have an OpenVPN tunnel from my home router to the private network where my Nextcloud server lives. Now, I can also connect to this VPN via the OpenVPN for Android app. What’s interesting is, I only encounter the «expected x got y» error under two conditions:
1.) the file is somewhat large (e.g. large JPGs or RAW images, as opposed to a .txt file which is fine)
2.) I am uploading from within my home network, via the OpenVPN tunnel.

It’s weird, because if I’m on my home network, but use the OpenVPN for Android app instead of routing through an OpenVPN server then everything works as expected.

I’m at a loss, unless there’s something wrong with my OpenVPN configuration. But the web UI works fine in all situations.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

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.

Источник

SabreDAVExceptionBadRequest: expected filesize 2584835 got 1114112 #9471

I have received the following fatal error messages:

SabreDAVExceptionBadRequest: expected filesize 2584835 got 1114112 2018-05-13T17:43:08+0200
SabreDAVExceptionBadRequest: expected filesize 61724962 got 26787840 2018-05-13T17:24:48+0200
SabreDAVExceptionBadRequest: expected filesize 2707452 got 1785856 2018-05-13T16:41:51+0200
SabreDAVExceptionBadRequest: expected filesize 1193422 got 884736 2018-05-13T16:30:52+0200
abreDAVExceptionBadRequest: expected filesize 61724962 got 4636672 2018-05-13T16:30:51+0200
SabreDAVExceptionBadRequest: expected filesize 8191601 got 2326528 2018-05-13T16:19:23+0200

Currently I do not receive any of these error messages anymore.

Version 13.0.2 is used, PHP Version: 7.2.5, mysql 5.7.22.

I was informed that there are problems regarding IOS 11.3.1. App version is: 2.20.8.00003, files are displayed for synchronization, but this is not done.

The text was updated successfully, but these errors were encountered:

I have overridden values ​​in the database, seems to work.
It is a bug. INSERT INTO oc_appconfig ( appid , configkey , configvalue ) VALUES (‘files’, ‘max_chunk_size’, ‘524288000’);

Hello, I have the same issue, please can you help me with the file ant the path to modify for this issue? Thank you.

This is done in the database. Open phpMyAdmin, search oc_appconfig Edit Value and insert.

Sometimes mistakes come again.
Wait for Update.

Worth noting this is sometimes caused by request_terminate_timeout being set too low in the PHP configuration if you’re using PHP-FPM. What happens is if the connection is too slow for a ‘chunk’ of a large file to upload, PHP-FPM just shuts off the connection part way through, and you see exactly this in the log.

did you mean pm.max_requests?

I know that this issue is already closed but according to some mailing lists and a Google search it seems to be a persistent problem. It could be caused for a lot of different reasons. I’d like to mention this thread: https://central.owncloud.org/t/expected-filesize-xxx-got-yyy-0/816 (Link edited on 2020/11/13) which lists many possible reasons.

In my case it seams to be caused by Apache’s reqtimeout module. I could observe sudden TCP resets sent by the server which lead me to the DoS protection mechanisms. Disabling the module eliminated the problem. Probably it is just a matter of correct settings which fit the Nextcloud server.

I’d further like to point out that I had the same problem on another Nextcloud server where we installed a web application firewall in between which in some cases terminated the sessions because of false positive signatures during the file upload. The Nextcloud server issued exactly this error message as stated within this thread and it was not obvious firsthand that it was caused by the WAF.

few years still same bug .. is impossible upload big file (5gb+) with any setting .. maybe is PHP really bad chooice for this

or have working setting someone ? share then ..

Since today I got the same issue.
Did anybody fixed this Problem? Please help.
nextcloud 15.0.2
Thx

Also seeing this issue.

Have a look at my comment from 25th of July. This probably may help you.

Interesting, I am running behind a reverse proxy, not sure if it could be the root of this. But your comment definitely gives me some avenues to pursue. Thanks!

This is done in the database. Open phpMyAdmin, search oc_appconfig Edit Value and insert.

I’m seeing the same issues. Can you please explain a little further what you mean by what you’ve posted? If oc_appconfig is selected, there are three columns. Here is the SQL:

INSERT INTO oc_appconfig ( appid , configkey , configvalue ) VALUES ([value-1],[value-2],[value-3])

so, which column does «Compare Value» go into?

I know that this issue is already closed but according to some mailing lists and a Google search it seems to be a persistent problem. It could be caused for a lot of different reasons. I’d like to mention this thread: https://forum.owncloud.org/viewtopic.php?f=17&t=32517 which lists many possible reasons.

In my case it seams to be caused by Apache’s reqtimeout module. I could observe sudden TCP resets sent by the server which lead me to the DoS protection mechanisms. Disabling the module eliminated the problem. Probably it is just a matter of correct settings which fit the Nextcloud server.

I’d further like to point out that I had the same problem on another Nextcloud server where we installed a web application firewall in between which in some cases terminated the sessions because of false positive signatures during the file upload. The Nextcloud server issued exactly this error message as stated within this thread and it was not obvious firsthand that it was caused by the WAF.

This is to confirm that disabling Apache’s reqtimeout module on Slackware 14.2 (apache-2.4.39) resolved this problem on my NC server. Thank You.

@rahra ‘s advice is spot-on. When I disabled the reqtimeout_module in Apache’s httpd.conf (centOS+CWP, latest version), the problem went away. Thank you very much!

Disabling reqtimeout_module sped up my nextcloud server enormously but unfortunately did not get rid of this error when uploading via webdav

© 2023 GitHub, Inc.

You can’t perform that action at this time.

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.

Источник

Была ли эта страница полезной?

0 / 5 — 0 рейтинги

Я пытался разместить ownCloud на моем сервере, но каждый раз, когда я пытаюсь, он говорит мне следующее:

Ваш веб-сервер еще не настроен должным образом, чтобы разрешить синхронизацию файлов, потому что интерфейс WebDAV, кажется, сломан.

Пожалуйста, проверьте руководство по установке.

Это моя установка:

Windows Server 2012 R2
IIS 8.5
PHP 5.5.11
ownCloud 6.0.3
MySQL 5.6.17

Я попытался Google погрешить ошибку, но я не могу найти ничего полезного.

Некоторые говорят, что я должен попробовать, если это работает:

[hostname]/remote.php/webdav/

и да, я могу перейти к этой папке, и я могу открывать файлы оттуда.

Календарь работает, и я также могу просто загрузить файлы в веб-версию ownCloud, единственное, что не работает, — это клиент синхронизации.

Клиент синхронизации ничего не говорит, просто не подключается (снимок экрана: http://prntscr.com/3p2apz)

Это журнал ошибок:

Warning     core    isWebDAVWorking: NO - Reason: [CURL] Error while making request: Could not resolve host: cloud.mcsoftworks.net (error code: 6) (Sabre_DAV_Exception)    2014-06-02T19:56:00+00:00
Warning     core    isWebDAVWorking: NO - Reason: [CURL] Error while making request: Could not resolve host: cloud.mcsoftworks.net (error code: 6) (Sabre_DAV_Exception)    2014-06-02T19:55:47+00:00
Warning     core    isWebDAVWorking: NO - Reason: [CURL] Error while making request: Could not resolve host: cloud.mcsoftworks.net (error code: 6) (Sabre_DAV_Exception)    2014-06-02T19:55:34+00:00
Warning core    isWebDAVWorking: NO - Reason: [CURL] Error while making request: Could not resolve host: cloud.mcsoftworks.net (error code: 6) (Sabre_DAV_Exception)    2014-06-02T19:55:34+00:00
Fatal   webdav  Sabre_DAV_Exception_Forbidden: Path does not exist, or escaping from the base path was detected 2014-06-02T19:54:37+00:00
Fatal   webdav  Sabre_DAV_Exception_Forbidden: Path does not exist, or escaping from the base path was detected 2014-06-02T19:54:36+00:00
Fatal   webdav  Sabre_DAV_Exception_Forbidden: Path does not exist, or escaping from the base path was detected 2014-06-02T19:54:36+00:00
Fatal   webdav  Sabre_DAV_Exception_Forbidden: Path does not exist, or escaping from the base path was detected 2014-06-02T19:54:36+00:00
Warning core    isWebDAVWorking: NO - Reason: [CURL] Error while making request: Could not resolve host: cloud.mcsoftworks.net (error code: 6) (Sabre_DAV_Exception)    2014-06-02T19:51:24+00:00

Это мой php.ini: http://pastebin.com/es3MB8Uh

У кого-нибудь есть идеи о том, как мне заставить это работать?

Virtual Filesystems

SabreDAV is built to easily adapt existing business logic onto a virtual network filesystem. This document explores how this can be setup.

• It is assummed in this tutorial that the reader has already went through the GettingStarted and FAQ manuals.
• In the code examples it is assumed all mentioned classes are currently loaded in through an include.

High-level API

SabreDAV is shipped with an API that should ease creating directory-tree structures.

Files and Directories

Files and Directories both implement the SabreDAVINode interface, this interface dictates the following methods should be implemented:

• delete() — deletes the file/directory.
• getName() — returns the file/directory name.
• setName($newName) — renames the directory.
• getLastModified() — returns the last modification time as a unix timestamp.

Additionally File objects need to implement the following methods:

• put($data) updates the data in the file.
• get() returns the contents of the file.
• getETag() — returns a unique identifier of the current state of the file. If the file changes, so should the etag. Etags are surrounded by quotes.
• getContentType() — returns the mime-type of the file.
• getSize() — returns the size in bytes.

Directories/Collections objects add the following:

• getChild($name) — Returns a File or Directory object for the child-node of the given name.
• getChildren() — Returns an array of File and/or Directory objects.
• createFile($name,$data) — Creates a new file with the given name.
• createDirectory($name) — Creates a subdirectory with the given name.
• childExists($name) — Returns true if a child node exists.

Inheritance tree

Next to the interfaces, there are two helper classes in this diagram ( SabreDAVFile and SabreDAVCollection ). These classes are an easy starting point, as they will lock down most operations by default (by reporting ‘permission denied’), so we can start with a read-only filesystem.

Implementation

Our read-only filesystem is going to be based off the standard server filesystem.

Getting the classes ready

For this demonstration we need to create 2 classes, one for a directory and one for a file. We’ll start out with the Directory class:

In the example is shown the absolute minimum of methods that need to be implemented in order to create a read-only directory. I’m hoping the code will speak for itself.

Same goes for the MyFile class:

It’s important thing to note is, that you should usually not pass strings around. Although the get() method can just return a string, especially with larger files it’s recommended to use streams (as shown with fopen). The put() and createFile() methods will always get a readable stream resource as arguments.

Setting up

I’m explaining the usage of your newly created server through code comments

This is not virtual

Thats right! This is where you come in. You can make your MyFile and MyDirectory classes completely independent from the actual underlying filesystem. The list of items returned from getChildren could be a list of blogposts, and the get method could return html data.

Write support

In order to get writing/modification support you should implement all the remaining methods. A good example of a completely built-out system like this can be found in the SabreDAVFS directory. This system should closely mimic apache’s mod_dav. Implementation of these is up to you (and optional) and is not written out in this manual, because at this point this should be fairly simple.

However, this is not enough. OS/X Finder and DavFS will demand you add locking support to your filesystem.

Источник

SabreDAVExceptionNotFound: File not found: groups in ‘addressbooks’ #10732

Comments

deeztek commented Aug 17, 2018

Steps to reproduce

1. Attempt to sync contacts with DAVdroid

Expected behaviour

Contacts should appear in nextcloud Contact application

Actual behaviour

No contacts appear. NC Admin —> Logging reports the following error:

Debug webdav SabreDAVExceptionNotFound: File not found: groups in ‘addressbooks’

Server configuration

Operating system:
Ubuntu 16.04 LTS

Web server:
Apache 2.4.29

Database:
MySQL 5.7.21

PHP version:
7.0.27

Nextcloud version: (see Nextcloud admin page)
13.0.5

Updated from an older Nextcloud/ownCloud or fresh install:
Updated

Where did you install Nextcloud from:
N/A

Signing status:

Nextcloud configuration:

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your Nextcloud installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM oc_appconfig WHERE appid = ‘user_ldap’;

Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Insert your webserver log here

Insert your Nextcloud log here

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) .

The text was updated successfully, but these errors were encountered:

Источник

Почему скачивается, но не закачивается файл в nextcloud по WebDav?

Установлен сервер nextcloud на ubuntu 16.04 Apache2.
Доступ по webdav работает нормально. На телефоне установлен Android 6.0.2 и программа FolderSync, которая в автоматическом режиме по webdav синхронизирует папку на телефоне и в nextcloud.
При синхронизации скачиваются файлы с сервера — всё ок. Но, если происходит попытка закачать файл с телефона на сервер, с сервера приходит следующая ошибка:

Debug webdav SabreDAVExceptionNotFound: File with name /test/Kn7IrxJgukU.jpg could not be located
/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Tree.php — line 76: OCADAVConnectorSabreDirectory->getChild(‘Kn7IrxJgukU.jpg’)
/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php — line 967: SabreDAVTree->getNodeForPath(‘files/***/tes. ‘)
/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php — line 1666: SabreDAVServer->getPropertiesIteratorForPath(‘files/***/tes. ‘, Array, 0)
/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php — line 355: SabreDAVServer->generateMultiStatus(Object(Generator), false)
[internal function] SabreDAVCorePlugin->httpPropFind(Object(SabreHTTPRequest), Object(SabreHTTPResponse))
/var/www/nextcloud/3rdparty/sabre/event/lib/EventEmitterTrait.php — line 105: call_user_func_array(Array, Array)
/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php — line 479: SabreEventEventEmitter->emit(‘method PROPFIND’, Array)
/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php — line 254: SabreDAVServer->invokeMethod(Object(SabreHTTPRequest), Object(SabreHTTPResponse))
/var/www/nextcloud/apps/dav/lib/Server.php — line 258: SabreDAVServer->exec()
/var/www/nextcloud/apps/dav/appinfo/v2/remote.php — line 33: OCADAVServer->exec()
/var/www/nextcloud/remote.php — line 162: require_once(‘/var/www/nextcl. ‘)

Подозреваю, что проблема с правами доступа. Может кто-нибудь лог расшифровать?

• Вопрос задан более трёх лет назад
• 1300 просмотров

Сам вопрос задал — сам отвечаю:

Изначально сам NC дает для WebDav ссылку вида:
https://DOMEN/remote.php/webdav/ — она не правильная., с ней синхронизация будет в одну сторону.

С ней всё синхронизируется и устанавливается.

Источник

HTTP 1.1 404 — Exception: SabreDAVExceptionNotFound #2783

Comments

plrunner commented Dec 20, 2016 •

Steps to reproduce

1. some not clear circumstances
2. folder shared among users
3. a subfolder is renamed by a user through the windows client
4. that subfolder is pretty simultaneously accessed by another user through his windows client (e.g. he updates a file in there)

Expected behaviour

sync would be expected to work smoothly

Actual behaviour

Several windows clients get RED complaining about CSYNC non able to find the folder (with the old name)

The DAV layer complains about the folder not being found (see Interesting log portion below).

In the web UI I see the folder just renamed containing all files as expected and also a zombie spurious folder having the old name. Trying to enter the latter brings me to the root folder. Deleting it just removes it from the view, but the zombie is back there when I refresh the page content.

workaround in order to get back to a stable state I have to make a backup of the renamed folder’s parent folder, delete the entire parent folder via web UI, wait for everyone to get synced and then restore the folder again.

Server configuration

Web server:
Apache 2.4

Database:
Mysql 5.7

PHP version:
5.7

Nextcloud version:
10.0.1

Updated from an older Nextcloud/ownCloud or fresh install:
Updated from 10.0.0

Where did you install Nextcloud from:
nextcloud website

List of activated apps:
Enabled:

• activity: 2.3.2
• admin_audit: 1.0.0
• comments: 1.0.0
• dav: 1.0.1
• federatedfilesharing: 1.0.1
• federation: 1.0.1
• files: 1.5.2
• files_external: 1.0.2
• files_pdfviewer: 0.8.1
• files_sharing: 1.0.0
• files_texteditor: 2.1
• files_trashbin: 1.0.0
• files_versions: 1.3.0
• files_videoplayer: 0.9.8
• firstrunwizard: 1.1
• gallery: 15.0.0
• notifications: 0.3.0
• password_policy: 1.0.0
• provisioning_api: 1.0.0
• serverinfo: 1.1.1
• survey_client: 0.1.5
• systemtags: 1.0.2
• theming: 1.0.1
• updatenotification: 1.0.1
• workflowengine: 1.0.1
  Disabled:
• encryption
• external
• files_accesscontrol
• files_automatedtagging
• files_retention
• templateeditor
• user_external
• user_ldap
• user_saml

The content of config/config.php:
<
«system»: <
«instanceid»: «ocq05beinini»,
«passwordsalt»: «REMOVED SENSITIVE VALUE«,
«secret»: «REMOVED SENSITIVE VALUE«,
«trusted_domains»: [
«removed.by.me»
],
«datadirectory»: «/var/www/nextcloud-data»,
«overwrite.cli.url»: «http://removed.by.me»,
«dbtype»: «mysql»,
«version»: «9.1.1.5»,
«dbname»: «nextcloud»,
«dbhost»: «localhost»,
«dbport»: «»,
«dbtableprefix»: «oc_»,
«dbuser»: «REMOVED SENSITIVE VALUE«,
«dbpassword»: «REMOVED SENSITIVE VALUE«,
«logtimezone»: «UTC»,
«installed»: true,
«loglevel»: 0,
«memcache.distributed»: «OCMemcacheRedis»,
«memcache.local»: «OCMemcacheRedis»,
«memcache.locking»: «OCMemcacheRedis»,
«redis»: <
«host»: «localhost»,
«port»: 6379
>,
«maintenance»: false,
«updater.release.channel»: «stable»
>
>

Are you using external storage, if yes which one: local/smb/sftp/.
NO

Are you using encryption: yes/no
NO

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.
NO

Operating system:
Ubuntu 16.04

Interesting log portion

The text was updated successfully, but these errors were encountered:

Источник

SabreDAVExceptionNotFound exception in PROPFIND response when file does not have a read permission bit #40460

Comments

mdusher commented Oct 31, 2022

I have been unable to find out how the affected file ends up with no read permission bit set on it to start with, but have been able to replicate it by manually removing the read permission that is set in the oc_filecache.

Steps to reproduce

1. Create a directory
2. Upload a file (multiple is better)
3. Remove the read permission from the file
4. Perform a PROPFIND on the directory

Example using owncloud/server:10.11 docker image

Expected behaviour

There should be no exception in the PROPFIND response.

Actual behaviour

A SabreDAVExceptionNotFound exception is printed mid-PROPFIND response making the response invalid.

The behaviour of the client varies.

• Chrome will list files up to the exception.
• Firefox does not list the parent directory at all.
• ownCloud sync client presents an «Unknown error» and does not continue syncing files.

Server configuration

Example above uses a fresh owncloud/server:10.11 docker image with no changes.

Web server error log

ownCloud log (data/owncloud.log)

The text was updated successfully, but these errors were encountered:

mdusher commented Oct 31, 2022

I have been able to mitigate the issue by skipping the file in the PROPFIND response if it is unreadable, but I’m not sure if this causes any other issues.

pako81 commented Nov 4, 2022

@jvillafanez what do you think?

cdamken commented Nov 4, 2022 •

2. Upload a file (multiple is better)

Uploading over the WebUI or over the sync client?

manually removing the read permission that is set in the oc_filecache.
3. Remove the read permission from the file

Why do you have to remove the read permissions? — This is not a normal procedure and no normal user has the possibility to access the DB to modify the permissions.
Why would you like to upload a file and remove the read permits?

Those are not normal steps to reproduce. why this file is uploaded and changed the behavior to read-only «automagically»
Is the folder shared with other users?

The pull request just ignores files that exist and won’t be shown in the WebUI and the sync clients, this will generate appearing and disappearing files without a reason when you run a occ files:scan
The user won’t see the missing file and will try to upload again and oC will say the file exists already.

cdamken commented Nov 4, 2022

I checked in an instance, I have arrond 500K files with other permisions that 27:

But with 26 I have none in about 3 million files

@mdusher Could you please check how many files have permissions with 26?

cdamken commented Nov 4, 2022 •

Could it be race condition?

1.- You upload a lot of files
2.- The files are being uploaded in the EOS storage, and at the moment they are being replicated are marked as read-only and so are saved in the oc_filecache
3.- The permits from the storage have been changed after the replication.

Step 4- Running an occ files:scan reads the files again and repairs the permits as they should be.

jvillafanez commented Nov 4, 2022

streaming vs no streaming

I think ownCloud is streaming the responses, at least for common webdav endpoints. This leads to faster response time because the data is sent as soon as it’s available. However, as shown in this ticket, errors aren’t properly handled because part of the data has already been sent. Response headers are already sent with a 207 status, and some data has reached the client. You can’t change the status code to a 404 and ignore all the data sent.

There should be already an config option to set the streaming option off (I’m not sure if we have an option or it’s hardcoded). If the streaming is off, all the data needs to be available in the server before sending it to the client. This leads to a very slow response time for large responses, specially with an infinity-depth propfind because the server need to check all the files. However, if an error happens, since no data has been sent yet, a proper error response could be sent.

I think the sabreDav should have a plan on what to do with the errors that happens in the response if streaming is active. I quite convinced that we depend on what sabreDav provides to deal with this issue, if it provides anything.

read permission missing

As far as I know, that comes from the FS. There is no reason for ownCloud to remove the permission, specially when no user can fiddle with permissions except for shares (which have their own permissions).

Without valid steps to reproduce the missing permission I don’t think we can do anything. Manually changing the permission in the DB is fine to reach a similar state in order to fix a different issue, which would be the streaming one, but the streaming issue is much bigger and needs a different approach. What’s more, fixing one issue won’t fix the other.

about the provided patch

I don’t think it’s a good idea. The actual storage implementation should be the one deciding whether the file should be skipped entirely or not. Skipping a file in the sabre connector seems a bad choice because any other component below the connector, and in particular the ownCloud FS, will still consider the file as valid but without read permission.
Note that the storage implementation should be the lowest piece of the dependency tree, so if the storage implementation says the file doesn’t exist, then it doesn’t exist for the whole ownCloud.

The sabre connector might need to deal with the error somehow. The main responsibility should be to transform the average FS view and actions into a sabreDav tree node. There should be no room to manipulate the data in a different way other than presentation

From my side, I think there are 2 problems: the «NotFound» exception happening (which should be handled somehow), and the exception (in fact any exception) breaking the XML format and causing issues to the clients.

Источник