OC 8.1/10.0 document will not open

[tony5]

I am using apache Server version: Apache/2.2.22 on owncloud 8.1 with PHP Version 5.4 I deleted the documents folder and reinstalled the documents app from this location. https://github.com/owncloud/documents/archive/v8.1.0.zip upgrade seemed to finish fine and permissions are proper. If I open a document the spinner will display for ever and when I hit the back arrow on the browser I will get a pop up box that says assertion failed. I had no issues with OC version 8.0.4

do you have any ideas? thanks!

the only errors I see are,

Error PHP Undefined index: REQUEST_URI at /var/www/cloud/apps/documents/appinfo/app.php#49 2015-07-09T18:15:02+00:00

Error PHP file_put_contents(/mnt/iscsi/disk0/owncloud/data/.htaccess): failed to open stream: Permission denied at /var/www/cloud/lib/private/setup.php#435 2015-07-09T18:03:19+00:00 Fatal webdav Exception: {"Message":"HTTP\/1.1 503 Service unavailable","Code":0,"Trace":"#0 [internal function]: {closure}(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#1 \/var\/www\/cloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Object(Closure), Array)\n#2 \/var\/www\/cloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(456): Sabre\Event\EventEmitter->emit('beforeMethod', Array)\n#3 \/var\/www\/cloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(254): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#4 \/var\/www\/cloud\/remote.php(64): Sabre\DAV\Server->exec()\n#5 \/var\/www\/cloud\/remote.php(135): handleException(Object(RemoteException))\n#6 {main}","File":"\/var\/www\/cloud\/remote.php","Line":55} 2015-07-09T18:02:50+00:00

this will repete when cron runs. Error PHP Undefined index: REQUEST_URI at /var/www/cloud/apps/documents/appinfo/app.php#49 2015-07-09T18:15:02+00:00

everything else seems to be running fine.

take care

[tony5]

I think the issue maybe that I have my data directory on my NAS and although the permissions are correct the documents app in 8.1 expects the files to be in the web server root. (/var/www)

I can load webodf from a web page with a file in the webserver document root fine for example but not from the NAS data directory.

everything else seems to work with 8.1

I had no errors in the logs with 8.0.4

take care

[wikon]

I can confirm this. documents has stopped working since update to OC 8.1. When I click a document, the window opens and the progress indicator is shown but nothing happens anymore. I have just updated to documents 0.10.0 but the issue still persists

[karlitschek]

@VicDeo

[iongchun]

I have the same problem. Just notice that a new document created after upgrade could be opened correctly, but old documents (even Example.odt) could not be opened. Looks like a compatibility issue.

[tony5]

I am taking a guess that the problem is with link generation in the documents app. this link will work with webodf.js "https://owncloud.domaine/owncloud/index.php/apps/files/download/Documents/Example.odt"

I am also using 'overwritehost' => and 'overwrite.cli.url' => I did try and remove those lines and use the internal server name but it still did not work.

[karlitschek]

@VicDeo is on vacation. @DeepDiver1975 Any idea if someone else can have a look? @cmonteroluque FYI

[tony5]

I was able to get documents working again but I had to do a fresh install. database corruption? I have no idea?

[wikon]

Suddenly I can open documents again. Weird. Still v0.10.0

[iongchun]

I have seen failed requests (404) with an old document (Example.odt):

10.0.0.3 - - [14/Jul/2015:03:53:19 +0200] "GET /index.php/apps/documents/ajax/genesis/78y5l03jx8mcxk8aksnaz43bxow8qp?requesttoken=TZoCDToz%2BTvnpZwqB0XY7sTr0ygjLo HTTP/1.1" 404 6134 "https://owncloud.xxx.org/index.php/apps/documents/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36"
10.0.0.3 - - [14/Jul/2015:03:53:19 +0200] "GET /index.php/apps/documents/ajax/genesis/78y5l03jx8mcxk8aksnaz43bxow8qp?requesttoken=TZoCDToz%2BTvnpZwqB0XY7sTr0ygjLo HTTP/1.1" 404 677 "https://owncloud.xxx.org/index.php/apps/documents/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36"

[DeepDiver1975]

Please download the code from the branch stable8.1 - I just merged another fix - https://github.com/owncloud/documents/tree/stable8.1

THX

[giancarlobi]

Great! now it works ... but there is a file that Documents can't open and the gear loader stay forever : the original example.odt, very strange. Anyway thank you very much !!! Giancarlo

[DeepDiver1975]

Great! now it works ... but there is a file that Documents can't open and the gear loader stay forever : the original example.odt, very strange.

please provide browser error logs and owncloud logs - THX

[giancarlobi]

The issue is described here https://github.com/owncloud/core/issues/17602 but with the last hotfix only happens with included example.odt file. Giancarlo

[enoch85]

@DeepDiver1975 Still, if I press update app, then the documents folder on the server gets empty and I have do download the zip package from Github to get it working again. If I try to reactivate it nothing happens, still an empty documents folder. Error in apps or documents?

[DeepDiver1975]

Still, if I press update app, then the documents folder on the server gets empty and I have do download the zip package from Github to get it working again.

Looks like we did not yet update the package on the appstore ...

[ghost]

@enoch85 See https://github.com/owncloud/documents/issues/508

@DeepDiver1975 Downloading the Appstore and put it manually into /apps folder works around this issue so the version on the appstore should be fine.

[iongchun]

I re-installed my ownCloud server with fresh DB and original data. Then installed this app of branch stable8.1, now all the documents could be opened again, but still could not be (pre)viewed.

Preview error:

10.0.0.3 - - [25/Jul/2015:05:04:49 +0200] "GET /index.php/core/preview.png?file=%2FExample.odt&x=200&y=200&c=1634080e978e8ce2837b85897cdb9bda&forceIcon=0 HTTP/1.1" 404 6182 "https://owncloud.xxx.org/index.php/apps/documents/" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:39.0) Gecko/20100101 Firefox/39.0"

View: no error, but shows binary in browser:

10.0.0.3 - - [25/Jul/2015:05:10:40 +0200] "GET /apps/documents/css/viewer/odfviewer.css HTTP/1.1" 200 6032 "https://owncloud.xxx.org/index.php/apps/files" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:39.0) Gecko/20100101 Firefox/39.0"
10.0.0.3 - - [25/Jul/2015:05:10:40 +0200] "GET /index.php/apps/documents/ajax/download.php?path=%2FExample.odt&requesttoken=iJWrGYobbd0rX%2F7t%2By4e6ke1rtWrtO HTTP/1.1" 200 40649 "https://owncloud.xxx.org/index.php/apps/files" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:39.0) Gecko/20100101 Firefox/39.0"
10.0.0.3 - - [25/Jul/2015:05:10:40 +0200] "GET /apps/documents/js/3rdparty/webodf/webodf-debug.js?_=1437793736157 HTTP/1.1" 200 151429 "https://owncloud.xxx.org/index.php/apps/files" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:39.0) Gecko/20100101 Firefox/39.0"

[vgiralt]

I've tried all trick in all related issues, no luck. Now I have THREE broken installs of OwnCloud 8.1.0 with documents 0.10.0.

In case it is of any use, I've been debugging using the browser developer tools while the spinner is running, and detected two different behaviors:

• New document. Two errors logged:

  • Step iterator must be on a step.
  • Inserting local cursor a second time.

  The document is created, but never appears in the browser, the spinner does not stop. But it can be downloaded.

• Existing document. It tries to retrieve something twice that gives a 404 (not found) error: https://server/owncloud/index.php/apps/documents/ajax/genesis/fddddc79c08e123233c4cc1f996179?requesttoken=noise%2Fclmip%2Bsomegarbage

I hope this is useful to someone who knows what and where to fix the problem.

[DeepDiver1975]

@VicDeo can you upload the latest code as of stable8.1 to the appstore - THX

[iongchun]

Upgrade to 0.10.1, still have some (two) documents working, others not working. I checked the database, found some bad path (genesis_url) in oc_documents_session table, they starts with "/documents/documents/", which seems wrong.

I backup the five ocdocuments* tables, then clear (truncate table) them, all the documents could be edited now, even the "Example.odt" ;) But I think if you want to keep the history, just correct the wrong genesis_url should also works.

[vgiralt]

@iongchun You are absolutely right my friend!!! You have saved me a lot of grief :-) removing the extra /documents from the genesis_url in oc_documents_session table brings back the documents to life once 0.10.1 is installed from GitHub.

@VicDeo, now, how about fixing the automatic upgrade so the documents app does not get deleted when the system makes you think it has been upgraded? Thanks.

[vgiralt]

I can confirm that the upgrade process is the culprit for the duplicate documents prefix in genesis_url.

Any installation I've submitted to the documents app upgrade has manifested the "double documents" bug.

[tony5]

when I upgraded from 8.0.5 to 8.1.1 I had to delete all references in the mysql database including the appid then everything worked.

I am not very good at databases and did not document the steps.

I hope what I did to get it to work does not hose your system.

[VicDeo]

I need to know documents version before upgrade to check.

Upgrade script prepends documents for all versions that are lower than 0.7.1, but 0.7.1 was in times of OC6 beta. (late 2013)

[asavah]

I can confirm this issue. Ubuntu 14.04, apache, mysql. Upgraded OC 8.0.4 to 8.1.1. Updated documents via gui to 0.10.1. Documents dead. Tried truncating all the ocdocuments* tables. No joy.

Even create new document via webgui does NOT work.

Spinning progress and nothing. Clicking "X" close button on the upper right corner produces:

ASSERTION FAILED:
editorSession should exist here

Nothing in OC or apache logs.

[enoch85]

FYI: Master works for me on Ubuntu 14.04 + Apache and MySQL.

[asavah]

Hmm. After all it seems to be a chromium issue ... Firefox works fine.

UPD: chromium started working too after I cleared browser cache (again?). I could swear I did it before writing.

[VicDeo]

@asavah does cleaning Chromium cache help?

[asavah]

@VicDeo Yes, it helped. Though I was sure I did clean the cache before writing in here.

[VicDeo]

As of September, 1 it is highly recommended to use documents v0.9.1 with OC8.0.x and documents 0.10.2 with OC8.1.x

Both versions are published at the app store

[VicDeo]

OC 7 still might be affected as https://github.com/owncloud/documents/issues/533 is ported to stable8 and above

[sneps85]

OC 8.1.3 with Documents 0.10.2 still not working... Opening a document causes spinning forever on all types of browsers. What to do?

[DeepDiver1975]

@VicDeo can you please cross test various documents apps(which are on the appstore) with our currently supported oc versions (7,8,8.1 and 8.2)? THX a lot

[VicDeo]

@sneps85 for ANY document?

[VicDeo]

@DeepDiver1975 Done, something like this

v	OC7.0.10	OC8.0.8	OC8.1.3	OC8.2.0
Documents 0.8.3	shipped	-	-	-
Documents 0.9.1	-	+	-	-
Documents 0.10.2	-	-	+	+
Documents 0.11.0	-	-	+	+

[scolebrook]

We're seeing 404 errors on the genesis url mentioned earlier in this thread. We've resolved the various csp related issues. Open a doc and share. Recipient opens the doc also and gets the endless spinner with 404 errors in the console. I've removed all documents rows from appconfig, dropped the documents tables and reset it all up. No change.

We're running 8.1.3 and 0.10.2. Issue has been observed when using a mix of FF and Chrome as both sharer and sharee. And with both odt and dock files, both freshly created. The first element in the url matches es_id column in oc_documents_session and I've not seen path issues with /documents/documents in the db row as I've seen mentioned elsewhere. We also have the line from the readme in .htaccess.

An interesting point is that the sharer will see the sharee appear in the right sidebar when they open the document and see the endless spinner. The sharer can also edit the document and work as normal with no error or indication that the sharee can't actually see anything. So it appears as though the sharer gets a notification that the other user has opened the document, the problem appears to be with the other user not being able to get the document to load.

This server was upgraded from 7.0.8 to 8.0.8 then 8.1.3 recently but documents was installed after the upgrade to 8.1.3. Let me know what I can do to help track down this bug. It's a real show stopper for this app and we were hoping to demo it to some executives at a meeting next week to show how ownCloud is more than file sync. I'm not familiar with how these genesis urls work or their purpose. Where should I start?

[scolebrook]

The 404 comes from lib/downloadresponse.php. The request is routed to Controller\DocumentController::serve when instantiates a new DownloadResponse object. It is passed, among other things, a string containing the internal username of the owner of the file in question. The __construct method on that object checks if the path /$user exists and if not sets the status to Http::STATUS_NOT_FOUND.

This constructor assumes that the path to the users home directory will match their internal username rather than querying the user object with getHome. We use the user_ldap backend with AD and have our home directory attribute set to use the upn attribute rather than objectGUID because it's easier to administer.

So the path it's asking about doesn't exist because it's asking for the wrong path.

The DownloadResponse class does use \OC\Files\View rather than stick exclusively to public and app framework classes. So using \OC::$server->getUserManager->getHome($user) would get the job done perfectly. The question is, is this the correct way to do this in this app?

[scolebrook]

Here's a "fixed" version of the constructor for downloadresponse. With this version, it works as advertised.

    public function __construct(IRequest $request, $user, $path) {
        $this->request = $request;
        $this->user = $user;
        $this->path = $path;

        $data_dir = \OC::$server->getConfig()->getSystemValue('datadirectory', \OC::$SERVERROOT . '/data');
        $fake_root = str_replace($data_dir, '', \OC::$server->getUserManager()->get($user)->getHome());

        //$this->view = new View('/' . $user);
        $this->view = new View($fake_root);
        if (!$this->view->file_exists($path)){
            parent::setStatus(Http::STATUS_NOT_FOUND);
        }
    }

Let me know if there's a better way.

[VicDeo]

Does anybody else here use user_ldap backend?

[VicDeo]

@scolebrook thank for your investigation. May I ask you to submit a pull request against master branch with these changes?

[ghost]

@VicDeo @DeepDiver1975 reviewers for the PR?

[VicDeo]

Does anyone here use ownCloud 8.1 with LDAP user backend?

[VicDeo]

oh, @scolebrook it seems you're on 8.1, so https://github.com/owncloud/documents/pull/570 is valid for 8.1 too.

[scolebrook]

@VicDeo Yes, we're on 8.1.3. I've tested https://github.com/owncloud/documents/pull/570 on our dev environment successfully and I've put it into production pending the next release of the documents app. Works perfectly with non-standard home directory naming.

[vgiralt]

@VicDeo, I have a deployment that's not yet into full production, with a 50K+ user LDAP backend.

[aptalca]

Just an update, I was getting the forever spinner ever since the update to 8.1 (and later 8.1.3) on all documents. I pulled the latest stable8.1 branch (a few commits ahead of 0.10.2). Restarted the service, refreshed the browser. Now everything works for newly created documents, but I still get the spinner for the existing documents (all of them) Thanks

PS. I am using it on AWS ubuntu, nginx, with encryption, no LDAP

[VicDeo]

@aptalca the simplest way to fix it is to truncate ocdocuments* tables (all unsaved changes to documents will be lost)

[aptalca]

Thanks @VicDeo that took care of it.

[VicDeo]

Fixed with https://github.com/owncloud/documents/pull/570 https://github.com/owncloud/documents/pull/572 https://github.com/owncloud/documents/pull/573

[danielberlin]

I have the same problem and I did a truncate on all truncate ocdocuments* tables, but problem remains unchanged in ownCloud 8.2.1. Spinner running forever for .docx, .odt working very well. What else do you suggest?