osm.api.myqnapcloud.com:443

Post your questions about myQNAPcloud service here.
Post Reply
mrw13
Starting out
Posts: 12
Joined: Sun Dec 13, 2020 2:44 am

osm.api.myqnapcloud.com:443

Post by mrw13 »

Hello

I've put my qnap 453 behind a squid proxy, and allowed it access only to the update URL. I did this because the qnap was making many requests to an S3 bucket endpoint and actually cost me money, such was the volume of requests (there is a checkbox to turn that off, it turns out: Hybrid Mount / Cloud Services / Disable - otherwise you end up with a TON of requests, which seems odd).

I'm surprised at how chatty the qnap software is. Approx once per second it tries to connect to osm.api.myqnapcloud.com:443 - does anyone know what that could be?

Thanks
Mike
Mousetick
Experience counts
Posts: 1081
Joined: Thu Aug 24, 2017 10:28 pm

Re: osm.api.myqnapcloud.com:443

Post by Mousetick »

So you enable 'cloud' features willy-nilly and then you wonder why they're accessing the cloud? That's a weird question to ask.

Apparently you had turned on 'Hybrid Mount / Cloud Services' but were not aware of it?

Perhaps you could check whether you have turned on any myQNAPcloud feature without you knowing it? That might explain why your NAS is talking to osm.api.myqnapcloud.com:443.
mrw13
Starting out
Posts: 12
Joined: Sun Dec 13, 2020 2:44 am

Re: osm.api.myqnapcloud.com:443

Post by mrw13 »

Mousetick wrote: Tue Feb 09, 2021 4:53 am So you enable 'cloud' features willy-nilly and then you wonder why they're accessing the cloud? That's a weird question to ask.

Apparently you had turned on 'Hybrid Mount / Cloud Services' but were not aware of it?

Perhaps you could check whether you have turned on any myQNAPcloud feature without you knowing it? That might explain why your NAS is talking to osm.api.myqnapcloud.com:443.
Hi, thanks for your feedback.

I've not done anything with the myQNAPCloud thing - is that related to osm.api.myqnapcloud.com ? There are other URLs but they are reasonable, like checking for updates every 12 hours - i allow those through.

The main issue here is the frequency of the osm.api endpoint, which seems excessive, and secondarily that its not clear what that endpoint is. I suspect its licensing checks, but again, frequency seems stupidly excessive. I haven't installed anything that has a purchased license.

On the Hybrid Mount / Cloud Service point - well, thats used by the backup service, and that particular backup job was not enabled. The Hybrid mount connection was not disabled, but as nothing was using it - why would it make so many LIST requests to the associated S3 bucket? Nothing was using that connection, yet the qnap decided to make:

400,000 PUT, COPY, POST, or LIST requests
4000 GET requests

I don't see why the connector would do that, and certainly not that volume, when nothing is using it.

Thanks
Mike
Mousetick
Experience counts
Posts: 1081
Joined: Thu Aug 24, 2017 10:28 pm

Re: osm.api.myqnapcloud.com:443

Post by Mousetick »

mrw13 wrote: Tue Feb 09, 2021 6:13 pm I've not done anything with the myQNAPCloud thing - is that related to osm.api.myqnapcloud.com ? There are other URLs but they are reasonable, like checking for updates every 12 hours - i allow those through.
From the domain name we can infer that it's probably related to myQNAPcloud, but it could be used by QNAP for some other NAS feature. You could always block the outgoing requests and see what happens. If you say it connects every second, you should notice if something breaks or the NAS will complain quickly enough.
On the Hybrid Mount / Cloud Service point - well, thats used by the backup service, and that particular backup job was not enabled. The Hybrid mount connection was not disabled, but as nothing was using it - why would it make so many LIST requests to the associated S3 bucket? Nothing was using that connection, yet the qnap decided to make:

400,000 PUT, COPY, POST, or LIST requests
4000 GET requests

I don't see why the connector would do that, and certainly not that volume, when nothing is using it.
When you lump the LIST requests together with the PUT, COPY and POST, we can't really tell if the bulk of requests made to S3 are for reading or writing. If the majority of requests are PUT, COPY and POST, it's clear that the S3 bucket is being written to (presumably for a backup). If the majority of requests are LIST, then it's clear the S3 bucket is being inventoried, which would be logical if it's mounted, perhaps to build a local shallow cache of the contents.

Is it really necessary to mount your S3 bucket on your NAS and keep it online all the time for your backup?

I don't know which backup software you're using but when I backup to Backblaze B2, the software I'm using (not QNAP HBS) connects to the bucket, does it job, and then disconnects. I don't need to "mount" anything or keep an online connection to the B2 bucket all the time.
mrw13
Starting out
Posts: 12
Joined: Sun Dec 13, 2020 2:44 am

Re: osm.api.myqnapcloud.com:443

Post by mrw13 »

Mousetick wrote: Wed Feb 10, 2021 10:41 am
When you lump the LIST requests together with the PUT, COPY and POST, we can't really tell if the bulk of requests made to S3 are for reading or writing.
Thats how AWS reports it.
Mousetick wrote: Wed Feb 10, 2021 10:41 am
If the majority of requests are PUT, COPY and POST, it's clear that the S3 bucket is being written to (presumably for a backup). If the majority of requests are LIST, then it's clear the S3 bucket is being inventoried, which would be logical if it's mounted, perhaps to build a local shallow cache of the contents.
Yes, logically list, which is excessive. There is no PUT/COPY/POST because its not being used to channel backups.

Mousetick wrote: Wed Feb 10, 2021 10:41 am
Is it really necessary to mount your S3 bucket on your NAS and keep it online all the time for your backup?
Thats how HBS seems to work, yes.

Anyway, i've blocked the osm endpoints and other stuff, and nothing broke. Suspect a lot is to do with telemetry, tracking, and licensing back to QNAP.
Post Reply

Return to “myQNAPcloud service”