"Network access is disabled" status although the network is enabled

[kollix]

I'm running the testpilot version https://github.com/owncloud/client/commit/57b65242e33f07120adbdbd07e79bc24be4c6144 on openSuse 13.2, KDE4 on a laptop connected to an OC server (openSuse 12.1, OC 7.0.4) on my local network. I suspend/resume my laptop and often after resume OC-client is stuck in the "unable to connect" state with the account status being "No connection to owncloud ... Unable to connect to ... Network access is disabled". But the network (ethernet cable only) is there and is active and I can reach the server (e.g. via browser). It seems OC-client does never try to contact the server again, and there is no obvious way in the OC-client UI to tell it "retry the connection" (What about a simple button above the "Delete" button) ?

[phil-davis]

You can right-click on the client UI area that says "Syncing selected files in your account with..." and choose "Pause". Then right-click again and choose "Resume". That "wakes up" the client, but it is not obvious. But it should have some more reasonable way of automagically trying to sync again when the network becomes available...

[phil-davis]

Also note that there is work happening to get back an actual Pause button (and I guess it will be a Resume button when Pause has been pressed) - #3584

[kollix]

Well, ...this is not close to anything a normal user (e.g. my kids) would know to do. And it does not work either. Just tried right now. The network access error is not going away.

[phil-davis]

I agree it is not obvious! And that other issue has work happening to get real buttons back for Pause/Resume. For me, I have been able to wake up the client sync again successfully on Windows. I guess your client is in a different state to what I have got in, some different combination of laptop suspend/resume, network disconnect/connect. I will let the devs and others who have similar configuration to you take over at this point :)

[guruz]

@kollix Can you run the client with --logfile - (or --logfile file.txt) to see what leads into this?

[kollix]

Have it. I can not attach the logfile here. Where to put it ?

[guruz]

https://gist.github.com/

If it contains private data: guruz@owncloud.com and olivier@owncloud.com

[ogoffart]

The error message comes from Qt, It thinks the network is not accessible (hence `QDisabledNetworkReply')

Maybe there is a plugin that sets the network as innaccessible. I have no idea why this would happen. @guruz: do you know?

[guruz]

@kollix Can you please check the settings dialog which Qt version the client is using?

[guruz]

(Maybe related to https://codereview.qt-project.org/#/c/113478/ )

[kollix]

On Thursday 13 August 2015 06:34:55 Markus Goetz wrote:

@kollix Can you please check the settings dialog which Qt version the client is using?

It says "Qt 5.3.2" - although this is wrong, since I do not have Qt 5.3.2 on my system. Checking which libs it really uses shows e.g. /usr/lib64/libQt5Svg.so.5.5.1 so it is clearly using my systems Qt 5.5.1 libs (openSuse from obs://build.opensuse.org/KDE)

P.S.: It would help if you allow Qt::TextSelectableByMouse on the QLabel showing this version information

Best regards/Sch�ne Gr��e

Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail /\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

[guruz]

@kollix thanks, selecting fixed.

Are you sure you're checking libs for the correct owncloud?

What does strings path/to/QtCore.so | grep 'Qt 5' say?

Do you have a self-compiled client?

[kollix]

On Thursday 13 August 2015 08:29:59 Markus Goetz wrote:

@kollix thanks, selecting fixed.

Are you sure you're checking libs for the correct owncloud?

yes. I did: ps -ef|grep testpilot koller 15140 29976 0 Aug13 pts/4 00:00:09 testpilotcloud --logfile /tmp/owncloud.log grep libQt /proc/15140/maps|head 7f730ce70000-7f730cec3000 r-xp 00000000 08:02 555862 /usr/lib64/libQt5Svg.so.5.5.1 7f730cec3000-7f730d0c3000 ---p 00053000 08:02 555862 /usr/lib64/libQt5Svg.so.5.5.1 7f730d0c3000-7f730d0c5000 r--p 00053000 08:02 555862 /usr/lib64/libQt5Svg.so.5.5.1 7f730d0c5000-7f730d0c6000 rw-p 00055000 08:02 555862 /usr/lib64/libQt5Svg.so.5.5.1 7f73177e3000-7f73178c2000 r-xp 00000000 08:02 574224 /usr/lib64/libQt5XcbQpa.so.5.5.1 7f73178c2000-7f7317ac2000 ---p 000df000 08:02 574224 /usr/lib64/libQt5XcbQpa.so.5.5.1 7f7317ac2000-7f7317ac7000 r--p 000df000 08:02 574224 /usr/lib64/libQt5XcbQpa.so.5.5.1 7f7317ac7000-7f7317aca000 rw-p 000e4000 08:02 574224 /usr/lib64/libQt5XcbQpa.so.5.5.1 7f731d572000-7f731d5b1000 r-xp 00000000 08:02 560776 /usr/lib64/libQt5Sql.so.5.5.1 7f731d5b1000-7f731d7b0000 ---p 0003f000 08:02 560776 /usr/lib64/libQt5Sql.so.5.5.1

What does strings path/to/QtCore.so | grep 'Qt 5' say?

strings /usr/lib64/libQt5Core.so | grep 'Qt 5' Qt 5.5.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.8.3 20140627 [gcc-4_8-branch revision 212064]) This is the QtCore library version Qt 5.5.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.8.3 20140627 [gcc-4_8-branch revision 212064])

I usually check the version with rpm:

rpm -qfi /usr/lib64/libQt5Core.so Name : libQt5Core-devel Version : 5.5.1 Release : 100.1 Architecture: x86_64 Install Date: Sa 01 Aug 2015 20:35:45 CEST Group : Development/Libraries/X11 Size : 2031294 License : GPL-3.0 or SUSE-LGPL-2.1-with-digia-exception-1.1 Signature : DSA/SHA1, Sa 01 Aug 2015 01:36:43 CEST, Key ID 27c070176f88bb2f Source RPM : libqt5-qtbase-5.5.1-100.1.src.rpm Build Date : Sa 01 Aug 2015 01:28:37 CEST Build Host : build81 Relocations : (not relocatable) Vendor : obs://build.opensuse.org/KDE URL : http://qt.digia.com Summary : Qt 5 Core Library - development files Description : Qt 5 Core Library - development files. Distribution: KDE:Qt55 / openSUSE_13.2

Do you have a self-compiled client?

no

Best regards/Sch�ne Gr��e

Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail /\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

[ogoffart]

Since Qt 5.5.1 is not yet released, i assume it is from git. What is the sha-1 ? Does it contains https://codereview.qt-project.org/#/c/113478/

It really looks like a Qt bug.

[kollix]

On Monday 31 August 2015 09:31:21 Olivier Goffart wrote:

Since Qt 5.5.1 is not yet released, i assume it is from git. What is the sha-1 ? Does it contains https://codereview.qt-project.org/#/c/113478/

I updated now to the latest Qt5.5(1) snapshot from the KDE:Qt55 / openSUSE_13.2 repository and checked also the sourcecode it was built from:

Yes, this source contains the mentioned patch.

I can still reproduce the problem. "No network access" despite having access.

Seems as if the Qt patch did not fix the problem

It really looks like a Qt bug.

---

Reply to this email directly or view it on GitHub: https://github.com/owncloud/client/issues/3600#issuecomment-136421812

Best regards/Sch�ne Gr��e

Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad?

() ascii ribbon campaign - against html e-mail /\ - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

[dragotin]

We're not going Qt5.5 for the next time until these things are fixed. Closing it here as it is upstream.

[vasyugan]

I'm lately seeing this every time I wake my laptop up from suspend.

[ghost]

Yep, me too. Since the latest upgrade to 2.0.2.

[vasyugan]

Latest version of the client lacks pause and resume functions. Therefore this is doubly annoying. Have to kill and restart the client to get it going again. Happens typically after resume from suspend.

[phil-davis]

"Latest version of the client lacks pause and resume functions." That is surprising - for each folder sync connection you can choose "Pause Sync" and then "Resume Sync". This should be in all 2.0.* releases and 2.1 nightly builds.

[vasyugan]

I most definitely can't. I'm on Arch Linux, using version 2.0.2. No pause sync. Only logoff (abmelden)

See attached screenshot.

[phil-davis]

It is available when you open the full settings window.

[vasyugan]

thanks! It used to be in the context menu of the status icon. Now that's well hidden..

[vasyugan]

For some reason, "pause sync" is greyed out, whenever this bug strikes, so this workaround fails:

[phil-davis]

Computer software is tricky stuff! It is to smart for itself. If it thinks it is off-line then it disables the Pause/Resume Sync options. That was modified recently - I think in 2.1 nightly builds. On my 2.1 I tried turning off all network, and I could still pause/resume sync. If you are in a position to use the 2.1 nightly builds then you could see what happens. Caveat: a nightly build could accidentally suffer some regression on any day, as new things are committed. So only do this if you know what you are doing and have proper backups of your files...

[guruz]

Can you guys check if the upstream patch here fixes it: https://codereview.qt-project.org/#/c/121724/

[guruz]

Qt patch also here: https://gist.github.com/guruz/47d5e9d47c76f1e6d371

[ogoffart]

(The grayed pause entry was fixed in 2.1 as part of issue #4010 )

[cen1]

We also encountered this bug on our own client (not owncloud related) with Qt 5.5.1. It randomly happens to like 10% of our users but works fine for the majority. Unfortunately we are stuck in limbo at the moment because we use VS 2015 so we can't downgrade and we have to wait for 5.5.6(?). In the meantime we will try to compile from latest Qt git and see what happens. Hopefully that will work and Owncloud can update to a stable bug-free Qt version down the road because as an Owncloud user this bug would totaly piss me off. :)

[MarcelWaldvogel]

I am currently running the ownCloud client 2.2.0 on Xenial. After every WLAN disconnect (including when closing the lid), ownCloud consistently stays in the "fake offline" mode. This makes the sync client essentially useless.

Unfortunately, even Ubuntu 16.04 Xenial still comes with Qt 5.5.1. Would it be possible to include some form of workaround in the ownCloud desktop client? Such as explicitely asking for the state. Or statically linking to a recent Qt version for the Ubuntu client.

As it is, ownCloud on Ubuntu laptops is not an option, which cannot be your goal.

[MarcelWaldvogel]

I tried installing the Qt 5.6.1 libraries from qt.io, which should contain the fix according to https://bugreports.qt.io/browse/QTBUG-46323 . ldd and /proc/$pid/map_files/´ show the correct paths when usingLD_LIBRARY_PATH=$HOME/Qt/5.6/gcc_64/lib`. However, reconnecting the network remains undetected by ownCloud client 2.2.0.

[dragotin]

@MarcelWaldvogel of course that is not our goal. But after all it is a question of things you can do in a day...

We have the patches named above in this thread, and it would be best if somebody of the Ubuntu Community would pick up those and convince the Ubuntu distro to take the patches and ship their Qt with it. That would obviously not only benefit owncloud user, but all Qt software on Ubuntu. I think I'd be willing to help with that approach, but not so much doing a workaround for Ubuntu only.

I hope that is understandable.

[MarcelWaldvogel]

@dragotin a) A non-working sync client is a killer argument for many environments. The users don't care where the fault lies. b) As mentioned in my comment just before yours here, even switching to Qt 5.6.1 which supposedly fixes the problem, does not improve things for me.

[dragotin]

@MarcelWaldvogel have you compiled again 5.6.1?

[guruz]

reconnecting the network remains undetected by ownCloud client 2.2.0.

The current release 2.2.2 ships with a workaround, please try that and report back.

[MarcelWaldvogel]

Ah, Xenial deactivated the OpenSUSE repository. 2.2.2 works like a charm! Thanks (and sorry for complaining)!

[ilmaisin]

To people who read this: if you are running Ubuntu 16.04 and can reproduce this problem, please click on the "Does this bug affect you?" link on this bug's launchpad entry so Ubuntu's developers will get the attention and the fix will be pushed downstream.

[kolayuk]

@guruz what workaround did you use? I dot the same issue on my app with iOS and Qt 5.7.0 and I have no ideas about it

[guruz]

@kolayuk The workaround is inside the client code.

Do you mean iOS or OS X? If you're building the OS X client yourself, you can try not having the bearer/ directory in the .app bundle Please create a new bug if this still affects you :)