I am running into a wall, there are so many issue cropping up with the way that it doesn’t accept paths and all sorts of stuff showing as incompatible.
I would really like to keep the backup targets on S3 as they travel across the internet, and SMB is simply not the right way to do it.
Currently I cannot set up a VPN between the two sites, so that is not an option.
Well I have a duplicati (stable 2.2.0.1) on a linux and a windows (in the test setup) client that I would like to backup using s3 storage.
But as far as I can see duplicati on especially windows, does not accept the ‘dialect’ of S3 that the qpkg package quobject offers.
I’ve spent most of 25 hours on trying to get this working, I mostly see ‘path is not allowed in connection string’ in duplicati.
I even found a minio thirdparty qpkg, and had to give up on that as well, partly because the minio was very old.
I would love to have a working setup using the s3 connection, as that is much simpler to set up as a remote storage over the internet, than using smb via a VPN.
Hmm, I just tried Kopia from the windows client, that runs through it without issues it seems, very interesting, I haven’t much experience with kopia yet…
Well that runs into a brick wall also at some point.
I am very confused about this QuObjects.
The nas is a TS-853A, and I have a QuObjects app there, but it doesn’t give me S3 credentials, it gives usernames with colons in it, neither duplicati nor kopia likes that as it is not S3 keys.
Then I tried using Chatgpt for help, and that tells me I’m using the wrong app, not the real QuObjects, and that qnap has made two apps with the same name?
So calling this S3 is not true if it can’t give real access key and secret key
I dont think you have read the discussion, or doesnt know what a DMZ is.
Let me explain.
If I place a device in a DMZ, it doesnt allow access to my lan, and I can control who can access it from wan with firewall rules. Som yes, dmz is, in this case, the only place to place it
DMZ is a matter if interpretation, either a network for web exposed services or a residential ‘free for all’ port forwarded mess (no distinction was made by you)
Still, never place a NAS in a DMZ as that implies web GUI and other services that should never ever ever be exposed to WAN. There is only very few services you should ever expose to WAN (those isolated via a VM/container in a dedicated subnet).
Exposing QuObjects directly to WAN could compromise your whole NAS as all QNAP services run internally with root permissions, so the whole NAS could be taken over that way (look at deadbolt, muhstick, qlocker,etc).
If you want to use publicly exposed S3 object storage on your NAS, do it via a container and a bridged or physical subnet (in this case the connection only to that subnet is fine, as it’s isolated from the actual NAS)
I would never show my QNAP or any other NAS to the internet as a whole, but placing it in a DMZ while experimenting with it, and then opening up in the firewall for specific IP’s like QNAP development, wouldn’t be a problem.
As an old QNAP betatester, I do have some experience with this.
Unfortunately the latest minio has been striped of everything, and no longer works, but I found a version from april that still has the gui.
I’ve been using most of a week working on this, and it now turns out that it could be the duplicati software that has a broken s3 interface somehow.
I can make it work towards idrive S2, no problems, but towards minio or QUObjects, just plain no, no matter what I do, I always end up in the error ‘path is not allowed’.
So I’ve now rolled back to duplicati 2.0.8.1_beta_2024-05-07, as recommended by chatgpt, and now I can actually make a backup, even towards QUObjects with the weird username access key with a colon it it.
So now I can remove the minio container, and the container station, and actually set up a backup with QUObjects.
Now I just need to figure out how to get it working with SSL.