b0m541

The issue with being unable to mount remote shares if DNS domain names are used for the server has been fixed in 2020.11.25a. @dlandon Thank you for the quick solution! Great responsiveness!

Thats what I did, since then 502 Bad Gateway, also still after the most recent update today.

None of the external programs such as ffmpeg or ebook-convert seem to some with the container or are not properly set up. Am I missing the point of using containers here? Why would those program names be pre-configured, but the programs are missing?

After the latest container update 2 days ago the database needed to be rebuilt. I made a completely new re-install, and now I get "502 Bad Gateway" on port 5000. Anyone else with the same issue? How to fix?

It definitely must be the DNS name handling. When I use the IP of the server, it does work. The DNS resolution does work on unraid using ping. forward and reverse zone are properly set up. One note: the servername I had used is a CNAME / alias. The reverse lookup of that IP is a different DNS name. I tried with the A record name instead of the CNAME. The online check does also fail. PS: I am quite sure that for diagnosing that, the diagnostics would have been of no big help.

Sorry, you asked for a screenshot So the names are as follows: Source: //servername.subnet.tld/foldername Mountpoint: SERVERNAME.SUBNET.TLD_foldername servername small caps, including alphanumeric characters and "-" dash all other components: small caps alphabetic characters How does the online test work? ping servername.subnet.tld shows that ICMP ECHO works. Also mounting the share manually on unraid does work without problems.

Sure, knock yourself out: The share is mountable on other machines, there are no additional firewall filters for the unraid host. The mount point name is the one generated by the plugin.

This is not about any particular file in itself. The whole set in itself is deanonymzing you 100%. Every setup described in that detail is unique. Some of the files would be sufficient to verify the dataset against a given setup, as e.g. the combination of hardware drive names in use.

I saw that they are anonymized, I looked at them, and my concerns are still there. The concept to post a complete set of diagnostics data publicly for anyone to read who desires to me is conflicting with the concept of data thriftyness. A request to Limetech will not resolve that conflict. I honestly doubt that all that data will be necessary to actually find why the mount will not work. I would assume it is also in your interest if users are willing to look into the problem on their own. So if you let them know, where to look, where is the harm? I understand th

Oh I see. No offense, that data is super privacy invasive and I do care about that. Please let me know what exact files you need to see where the problem is, I might then as well be able to understand the problem on my own.

Wow that was fast. where to find the shares diagnostics?

Mounting remote SMB shares does not work for me in version 2020.11.23b I can create an entry fine, and while doing that it will show the available shares. After the entry is created the "mount" button is greyed out and cannot be clicked. I did not find any messages relating that in the regular log files, maybe I looked in the wrong location. This is a rather urgent topic for me, since I have several containers who use remote shares.

Same problem here. The web ui works, searching on the UI is working OK. However, when using the button "Lookup in Browser"in Picard it will produce the same unspecific error message Internal Server Error Oops, something went wrong! Error message: (No details about this error are available) Time: 2020-11-22 11:15:21 UTC Host: 3ba754cc6c04 URL: http://myunraid.test:6000/taglookup?artist=redacted&release=redacted&track=redacted&tracknum=redacted&duration=redacted&filename=redacted&tport=8000 Request data: $VAR1 = { 'query_parameters' => { 'file

Hey guys, I have a problem with the unifi controller that I cannot figure out and fix on my own. I had the latest branch container running. The whole thing started with an UAP AC Mesh that was connected using mesh to a wired UAP becoming disconnected and when power-cycled not being able to get connected again. I then wired that UAP AC Mesh to the subnet where the controller and all unifi components are wired. A reset and even a factory reset resulted in the UAP AC Mesh being shown as "Adopting" in the controller but not making any progress. I then realized t

This may be normal for this container, I wouldn't call it optimal. So you are right, the logs count against "Writable" instead of "Log", and actually the logs should be placed in the log folder on appdata... But hey, you get what you pay for and thanks for your help.