You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
according to the changelog of 7.2.0 and this ticket (#10956), the possibility to configure path-style for S3 was removed. Later two mechanisms were added to automatically detect when path-style should be used:
Situation 1: When server is an IP address: e5e2a97
Situation 2: When A/AAAA record for bucket.hostname.example is answered with NXDOMAIN: af0c7ed
However, there are use-cases when both situations don't apply but path-style might still be required for the connection to work.
For me situation 1 will not apply as I have to use a domain name so the SSL certificate can be verified. Situation 2 also does not apply because we're using wildcard DNS records for *.hostname.example. In this case Cyberduck checks for a A record of bucket.hostname.example which obviously exists but it does not point to the correct system as the S3 system is configured to work with path-style buckets only.
Other people are having the same issue with wildcard DNS setup (#10956#comment:10) or with a nameserver of their provider which answers to requests with own IP addresses (#10888#comment:31, bad practice but it's out there..).
Therefore it would be great to have a config option to disable the automatic detection and specifically set the mode to path-style.
Besides that it seems that the mechanism for situation 2 (auto-detect with DNS lookup) is broken on MacOS 11.0.1 and Windows 10, Cyberduck 7.7.2. I tried it with a different S3 system that does not rely on wildcard DNS records. I am able to connect to the system, list buckets and files but as soon as I initiate a download, an error message appears, clearly indicating it is trying to resolve the non-existing domain and fails:
Failure to read attributes of file.png.
bucket.hostname.example. DNS is the network service that translates a server name to its Internet address. This error is most often caused by having no connection to the Internet or a misconfigured network. It can also be caused by an unresponsive DNS server or a firewall preventing access to the network.
So it seems as if the auto-detection works for the initial connect and file browser but not for downloading files.
Let me know in case I should provide more details.
The text was updated successfully, but these errors were encountered:
Hi,
according to the changelog of 7.2.0 and this ticket (#10956), the possibility to configure path-style for S3 was removed. Later two mechanisms were added to automatically detect when path-style should be used:
NXDOMAIN
: af0c7edHowever, there are use-cases when both situations don't apply but path-style might still be required for the connection to work.
For me situation 1 will not apply as I have to use a domain name so the SSL certificate can be verified. Situation 2 also does not apply because we're using wildcard DNS records for
*.hostname.example
. In this case Cyberduck checks for a A record ofbucket.hostname.example
which obviously exists but it does not point to the correct system as the S3 system is configured to work with path-style buckets only.Other people are having the same issue with wildcard DNS setup (#10956#comment:10) or with a nameserver of their provider which answers to requests with own IP addresses (#10888#comment:31, bad practice but it's out there..).
Therefore it would be great to have a config option to disable the automatic detection and specifically set the mode to path-style.
Besides that it seems that the mechanism for situation 2 (auto-detect with DNS lookup) is broken on MacOS 11.0.1 and Windows 10, Cyberduck 7.7.2. I tried it with a different S3 system that does not rely on wildcard DNS records. I am able to connect to the system, list buckets and files but as soon as I initiate a download, an error message appears, clearly indicating it is trying to resolve the non-existing domain and fails:
So it seems as if the auto-detection works for the initial connect and file browser but not for downloading files.
Let me know in case I should provide more details.
The text was updated successfully, but these errors were encountered: