Hello.
I’m on Fedora 35.
I have this weird issue with the pcloud service (and with pcloud only, no problem with anything else).
I’ve installed the pCloud Drive app long time ago and and it worked fine for a while, then it somehow stopped dialoguing with their servers, i.e. I was able to browse my pCloud folders structure (also in Nautilus) but I couldn’t download/upload anything.
pcloud on Win10 on the same machine works fine, therefore it’s not an ISP problem.
I tried uninstalling and reinstalling the pCloud imagekit but the problem remains.
Launching it from /usr/bin, it gives: { Error: getaddrinfo ENOTFOUND api.pcloud.comapi.pcloud.com:443
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:50:26)
errno: ‘ENOTFOUND’,
code: ‘ENOTFOUND’,
syscall: ‘getaddrinfo’,
port: 443 }
Down: Everything Downloaded| Up: Everything Uploaded, status is LOGIN_REQUIRED
STATUS -------------> 4
Then, after logging in, I get: Down: Everything Downloaded| Up: Everything Uploaded, status is CONNECTING
STATUS -------------> 12
Down: Everything Downloaded| Up: Everything Uploaded, status is OFFLINE
STATUS -------------> 11
Credentials are correct.
I don’t understand if it’s a DNS problem/firewall problem or else.
I didn’t install any additional firewall. My DNS points to my GW which is my router.
thx for your reply.
I already opened a ticket with pcloud but unfortunately their response was inconclusive: they suggested to remove completely pcloud and re-install the last version.
That I did (with their last client version), but the behaviour didn’t change.
According to pcloud support team, “the problem seems to be related to your operating system since you can access pCloud via Windows”.
I tried to post it here, hoping that somebody else is having the same issue.
I can add another point: if I try to go to https://my.pcloud.com from a web browser, the page
remains stuck indefinitely.
I’m not using any VPN and I didn’t specify any particular firewall rule.
$ resolvectl query plcoud.com
plcoud.com: 95.211.219.67 -- link: eno1
-- Information acquired via protocol DNS in 63.6ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
$ resolvectl query my.plcoud.com
my.plcoud.com: 69.162.80.54 -- link: eno1
-- Information acquired via protocol DNS in 368.8ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
$ resolvectl query api.pcloud.com
api.pcloud.com: 74.120.9.121 -- link: eno1
74.120.8.6 -- link: eno1
74.120.8.226 -- link: eno1
74.120.8.14 -- link: eno1
74.120.8.15 -- link: eno1
74.120.9.233 -- link: eno1
74.120.9.234 -- link: eno1
74.120.8.13 -- link: eno1
74.120.9.235 -- link: eno1
74.120.9.89 -- link: eno1
74.120.9.90 -- link: eno1
-- Information acquired via protocol DNS in 11.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
Unfortunately yes: on win10 (same machine, same network infrastructure), it works fine, both via desktop and via app.
Not sure if their versions follow the same numbering for both operating systems (I guess not): for sure I’m using the last Win10 version and the last linux version.
Will do tonight. I don’t have access to the machine at the moment.
So far I tried with different browsers: Firefox, Gnu Icecat, Chromium: same behaviour on all of them. But I haven’t tried it in a private window.
– Information acquired via protocol DNS in 14.6ms.
– Data is authenticated: no; Data was acquired via local or encrypted transport: no
– Data from: network
– Information acquired via protocol DNS in 30.0ms.
– Data is authenticated: no; Data was acquired via local or encrypted transport: no
– Data from: cache network
api-pcloud-com: resolve call failed: ‘api-pcloud-com’ does not have any RR of the requested type
So it’d seem that my system can resolve all of them except for api-pcloud-com, which I don’t understand why.
I tried to ping the first IP given by your resolvectl and it works fine, therefore it’s not a problem of pure IP reachability.
PING 74.120.9.121 (74.120.9.121) 56(84) bytes of data.
64 bytes from 74.120.9.121: icmp_seq=1 ttl=56 time=147 ms
64 bytes from 74.120.9.121: icmp_seq=2 ttl=56 time=147 ms
64 bytes from 74.120.9.121: icmp_seq=3 ttl=56 time=147 ms
64 bytes from 74.120.9.121: icmp_seq=4 ttl=56 time=148 ms
Back to the browser, I was able to reach the login page with Firefox via a private windows -as you suggested- but, after inserting the credentials, the page gets stuck again.
I guess clicking on the login button points to the same api-pcloud-com url.
At this point I think the problem is resolving the api-pcloud-com url, but it seems to be a system-wide problem, given that I can’t reach it via broswer, nor via terminal or app.
Does Fedora have a blacklist somewhere that could block resolving the url?
P.S.: I had to change all the “.” with a “-” because new users cannot post more than 2 links apparently…
Yeh, I guess you can try to change your DNS settings in network manager to use some well known public ones and see if that helps? Here is the Google one:
You should be able to set the DNS in network manager for each connection
Thank you @ankursinha .
Putting 8.8.8.8 as DNS server (instead of my router’s) solved the problem.
I still don’t understand why the problem doesn’t appear on win10 on the same machine and same network infrastructure, but that’s out of scope for this forum, therefore I’m marking it as solved.
Yeh, that’s very odd. I guess you could check to see what DNS is being used on Windows. Maybe it’s not the default one that your internet provider uses, and something Windows sets? Really not sure.
yes: on win10 (same machine, same network infrastructure), it works fine, both via desktop and via app.