Do you still get errors in your logfiles? The missing cache-warning is not error, most hosting solutions don’t provide caching modules (at least not redis) and they are no requirement (they make the cloud just a bit faster).
Strangely enough, the only error message i can find in the log now (logging “all”) is related to something with webdav, which sounds more like a problem with a calender or such but not a reason for an unwanted logout for a browser session?
Exception: {“Message”:“HTTP/1.1 401 No ‘Authorization: Basic’ header found. Either the client didn’t send one, or the server is mis-configured”,“Exception”:“Sabre\DAV\Exception\NotAuthenticated”,“Code”:0,“Trace”:“#0 [internal function]: Sabre\DAV\Auth\Plugin->beforeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#1 /kunden/XXXX/XX/3rdparty/sabre/event/lib/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#2 /kunden/XXX/XXX/3rdparty/sabre/dav/lib/DAV/Server.php(446): Sabre\Event\EventEmitter->emit(‘beforeMethod’, Array)\n#3 /kunden/XXX/XX/3rdparty/sabre/dav/lib/DAV/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#4 /kunden/XXX/XX/apps/dav/appinfo/v1/caldav.php(84): Sabre\DAV\Server->exec()\n#5 /kunden/XXXX/XX/remote.php(165): require_once(‘/kunden/XXXXX…’)\n#6 {main}”,“File”:“/kunden/XXXXXX/XX/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php”,“Line”:188,“User”:“(unsername, deleted here)”}
I am another one of those DomainFactory customers. My first approach was also adding a custom temporary directory. That solved some of my problems. But (as far as I can judge that by now) what really solved my constant unwanted logouts/relogins (to add another keyword for search engines) was changing session.save_path in php.ini:
session.save_path = /kunden/accountNumber_zipCode/tmp
If your df account is older, the folder structure might look different. More info on that: Probleme beim Owncloud Upload / session.save_path? and ownCloud: Problem mit Session Path
I hope that helps someone.
2 Likes
Thanks for your tip, however n trying to follow it up - where do I find “php.ini”? thanks!
Thanks wow, another new world which has to be learned to be able to use NC…
Any idea what should be in such a php.ini included as well?
It seems i dont have any php.ini so far
thanks
90% of the time is /etc/php/version number/apache2 (if you are using apache).
For example, my php.ini is inside /etc/php/7.0/apahce2/
Dear Florian,
unfortunately, for subdomains the automated domain factory php ini editor doesnt work, so i´ll probably have to put a php.ini in the subdomains root myself. can you post your (anonymized) php.ini here?
With the amount of issues with DF, perhaps they’re not the best host to use. @lex I didn’t realise you’re externally hosted, which is probably not making your life easier. We can’t know what they’re doing on their systems to offer you your server. Have you contacted them to help troubleshooting?
Yes, I have contacted them, and as I have stated in several messages here - they have been really extraordinary helpful. I never got an answer from them like “Thats not our job” or “We can´t help you with owncloud/nextcloud”. They have been extremely responsive and without their help, NC wouldnt be running on our webspace at all. So I wonder why you thing DF would probably be a bad choice for an NC-webhoster. Just from my problems or did you get other feedback as well?
So my last question was here if I can get some info on a recommended php.ini, next step would be for me to contact DF-support to ask them for implementation.
Thanks
Based on the number of people having issues with them, not just yourself.
1 Like
Ok, so I am back at the previous square again, dont have a php.ini (which i could try to implement with the help of the hosters hotline)…
Here’s a copy of the demo server php.ini:
I don’t guarantee compatibility with your host however, though the PHP OPCACHE settings are bolted onto the bottom as requested by the installation.
That solved it for me. Doing a php.ini edit on a webserver is a daunting task for those who don´t even know what that is. However, basically I just had to run the editor, input only the line from @Florian_1990 and create a tmp-directory in my webspace. Problem immediately solved.
Thanks!
1 Like
I have a same problem, but the solution does not work for me. I have my own server and /tmp is writeable for everyne. php tmp is left to default (/tmp) as well as nextcloud tmp (/tmp/nextcloud). I do not see any error anywhere - I look at apache logs as well as nextcloud ones. A strange observation - the /tmp/nextcloud has not been created - I made it by hand and chmoded to 777, however nothing ever gets written there. What would be a operation to test if this works? What are other possible steps to solve this? The unwanted logout in my case happens regulary, but not all the time. Still very annoying.
Hi all!
For Domainfactory-Users that could help: https://www.df.eu/forum/threads/76960-Owncloud-8-1-1-opendir(-tmp)-failed-to-open-dir-Permission-denied
Best,
Chris
1 Like
Thanks for the Tip! Worked fine for me!
I seem to have the same issue with the official Nextcloud 13.0.4 docker image (Apache version). Seems strange as you would assume the php.ini is configured correctly there…
Any ideas?
Try a different browser, it can also be some ad/script-blocker or anti-virus.
Nothing uncommon here, just default Firefox 61.0.1 on Linux.
What makes me suspect that the Docker image has an issue is that I run two Nextcloud instances, one on a shared hosts that exibited the exact issues as explained in this thread and which I fixed by applying the recommendations here. The other is the mentioned Docker install (Apache image running through a Traefik reverse-proxy). I am accessing both instances though the same browser and one stopped this behavior after appying these fixes and the other is still doing it…