remote.php errors after upgrade #23610
Comments
|
Sorry for the formatting issues. I tried to tweak it, but ended up making it worse and less readable |
|
Looks like the upgrade didn't properly setup remote.PHP. Please have a look in the DB - table OC_appconfig for entries which hold the value app/files/appinfo/remote.PHP That value has to be changed to |
|
DeepDiver1975, thanks for the info. Most of this is put here so someone else can see what I did...but I also put it here on the hopes that I'll get some confirmation Query: gives me running query gives me the one row I'm going to update now I'll update it confirm the change with I can see the change Do I need to update anything else in that table? Results after testing = I still get the same error when I login. I also get the same errors in the owncloud log. |
|
@DeepDiver1975 -- can you confirm what the values should be in the table? After testing the one entry above and it didn't work, I ran the following queries: query 1 that gave me Note the remote_dav and remote_files line. The remote_dav one uses v2 instead of v1 like you had. The remote_files one you gave me ends in webdav.php NOT remote.php like the others in the select. I then ran these two update queries (I know you didn't explicitly say, but they made the two rows agree to something). I was just testing a theory here That gave me It didn't work so I set the two rows back to what they were before I started: Oh, after the updates but before testing, I bounced apache (just in case) |
|
You have to update the remote_webdav entry as well. Really strange they did not get updated properly. |
|
Do you have log entries from the time where you ran the upgrade, in case there were errors ? |
|
@DeepDiver1975 just to confirm ... all 8 rows shown above should have their configvalue set to dav/appinfo/v1/webdav.php (I hate to have to undo something because I missed something simple) edit - see below |
|
@PVince81 let me check. I know I ran occ with the --verbose flag and didn't get any errors reported to the console. |
|
Here's all I find in my owncloud.log file around the upgrade time: From looking at my other upgrades in the log, that looks normal. I do see some errors from a previous upgrade so I know errors had been written (I had a mysql problem relating to my lock table size) Perhaps there could be an enhancement request made: when occ is run with --verbose, major steps done are written to the owncloud.log file (just like what gets printed to the console...starting/finished type messages) |
|
after looking through the code, I found what I thought were the correct values here in core/apps/dav/appinfo/info.xml. I updated my table to: I can login via the web interface now and see files. I also still have my calendar and contacts. My sync client appears to work too. I just checked my android app and all appears ok there. Looks like that resolved it edit ... checked my caldav and carddav connections on android after posting. They work too. |
|
@TheOtterslider the table is supposed to look like
|
…revent migration issues like #23610 - furthermore there is no need to dynamically lookup all the endpoints we already know
|
Thanks for the info @DeepDiver1975 . I have an entry you don't have: remote_filesync Should it be updated to something? |
no - this was never used |
|
Super. Thanks for all the help. |
|
By the way, from where I sit the issue is resolved. Should I close it now or wait for someone else to do it after a certain milestone? |
Happy to help out! Take care |
|
Please help me, I'm getting these same errors but I have no clue how there were solved for TheOtterslider. What commands do I need to issue to alter my DB table? |
|
@88fingerslukee -- What I did to resolve the problem was update some values in the database. The upgrade should have done it, but it didn't ... for some reason.
There is way too much that could go wrong here if done wrong and way too much dependent upon your exact configurations. Here's an outline of what needs done: 0 - back up your database. Now do it again. Check it. If you hose this, you'll have to restore it. I cheat and cron the mysqldump command for all my active databases every night. Before I do an upgrade, I'll run it manually. You can do this by: 1 - login to your database. I used the mysql command line version to login as the root user: then enter the password when prompted. 2 - you need to switch to the correct database: 3 - run a select to check the values. This depends on the table prefix you used when you installed ownCloud the first time. 4 - this will spit out something like this: 5 - compare your values to what the table is supposed to look like (#23610 (comment)) 6 - update anything that needs updated. I did it one at a time by running this query. The generic format for this in SQL is update TABLE set COLUMN = VALUE [WHERE]: If done correctly, you should see something that says one row was updated. Once everything is done, you should be good to go. If you have mysql, the commands above will give you a good idea where to start. There are easier ways (especially if you are running owncloud on a hosted server that has phpmyadmin), but that's how I did it. They are also the most common denominator provided you have command line access to the server. I personally don't have phpmyadmin installed on my box so I can't help you out there too much. Edit for formatting and to say that if you see something IN ALL CAPS above, it needs replaced with your specific values |
|
@TheOtterslider |
|
Had the same issue, updated MySQL tables, this fixed everything except for the external links 'Download' button seemed to work, but no files could be seen on the web Logs: require_once(): Failed opening required '/var/www/html/owncloud/apps/files_sharing/publicwebdav.php' (include_path='/var/www/html/owncloud/3rdparty/pear/console_getopt:/var/www/html/owncloud/3rdparty/pear/pear_exception:/var/www/html/owncloud/3rdparty/pear/pear-core-minimal/src:/var/www/html/owncloud/3rdparty/pear/archive_tar:/var/www/html/owncloud/3rdparty/phpseclib/phpseclib/phpseclib:/var/www/html/owncloud/lib/private:/var/www/html/owncloud/config:/var/www/html/owncloud/3rdparty:/var/www/html/owncloud/apps:.:/usr/share/pear:/usr/share/php:/var/www/html/owncloud') at /var/www/html/owncloud/public.php#74 SQL entry: +-------+---------------+--------------------------------+ Changed the value to 'dav/appinfo/v1/publicwebdav.php'
This fixed the issue |
|
Hi guys, solved the very same issue for me, too. |
|
I hit this issue today, upgrading from 8.1.something to 9.1.0, has this not been patched? |
|
Just hit this bug when upgrading from 8.2.10 to 9.0.8. However I had two issues that made me revert to 8.2.10:
|
|
@Aikhjarto -- wasn't the upgrade to 9 when ownCloud made the change that
If I'm right, redo the upgrade (all the steps), login as your ownCloud admin user and reactivate the calendar app |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Steps to reproduce
Expected behaviour
It should work
Actual behaviour
When I login, I get a "this directory is unavailable, please check the logs or contact the administrator error message displayed (for all users)
When I check the logs, they are full of this:
I check...that file doesn't exist (/var/www/html/owncloud/apps/files/appinfo/remote.php). This is weird because I just unzipped the owncloud directory directly from the tar. But, I try to copy it and I get other errors (so I deleted it from files/appinfo and leave it in the root). I decide I'll just get it from github....hmm, it doesn't exist there.
If I go to https://MyHost/owncloud/remote.php/webdav I get a 500 error thrown
If I go to https://MyHost/owncloud/remote.php/dav I get prompted to login and then see the standard "this is the webdav interface" message
I think the root problem is something messed up with webdav. When I upgraded to 8.2.3, I had to run the upgrade twice because I had some similar problems. When I reenabled the contacts and calendar apps, then did the upgrade again everything started working (in 8.2.3). I can go in and enable apps,once I got to that point, I decided to upgrade to 9.
Just to clarify, what happened in the 8.2.3 upgrade was I upgraded, logged in just fine, enabled the contacts app, then got kicked out to the "you need to upgrade" web screen. I reran the upgrade from the command line. Same with calendar...enabled it, got kicked out to the "you need to upgrade" screen, so I rerean it from the command line. By the time I was all finished, everything worked
Some more information, calendar and contacts work great...it is only files that is messed up.
RealRancor on the forums thought it was related to .htaccess issues. I went and manually got the htaccess from the 9.0.1 beta branch. it didn't appear to be different than the file I had, but I put it in anyway. No change.
Server configuration
Operating system: centos 6.7 (final) Web server: apache 2.2.15 Database: mysql 5.1.73 PHP version: 5.6.18 ownCloud version (see ownCloud admin page): 9.0.0 Updated from an older ownCloud or fresh install: upgrade from 8.2.3ownCloud log (data/owncloud.log):
Special configuration (external storage, external authentication, reverse proxy, server-side-encryption): nothing special
Login as admin user into your ownCloud and access
http://example.com/index.php/settings/integrity/failed
paste the results here.
List of activated apps:
If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder
The content of config/config.php:
If you have access to your command line run e.g.:
sudo -u www-data php occ c
from within your ownCloud installation folder
or
Insert your config.php content here
(Without the database password, passwordsalt and secret)
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
Browser: - Chrome
Operating system: Mac OSx 10.11.3
Logs
Web server error log
Edit - formatting
The text was updated successfully, but these errors were encountered: