iTHiNDiL

Hi @Roxedus, The DNS resolution stop working last night after updating the container with the latest version. After performing some tests the port 53 is closed from the network to the container.

After the last update DHCP start working without a problem, looks like they fixed, whatever it was ...

Thanks for your quick response @Roxedus. Folks, until the latest version of the container is updated with the Framwork 5.0 files we must change the tag as @alientim said: Edit: Already working with "latest" tag

Same problem here, but I belive that the issue i'ts not on Technitium DNS Server, the container do not contain Framework 5.0 files. @Roxedus, if you have a moment can you confirm that the problem is on the container? thanks

Nope, I was using bridge and after your question I did tried to use a manually created network, didnt' work I also tried to use host and curiously port 67 was not maped:

Don't think this is an answer for the question: This only will flag the recycle bin hiden, if you have "show hidden files" enabled you still be able to access the bin. @NasOnABudget, right now, as dlandon said a few posts before, there is no way to accomplish this, the bin have the same permsissions as the shared folder.

Yes, by default it's disabled but i did enable the scope and restart the container just in case. The problem is that the port UDP 67 it's closed when I test the port with PortQryUI, it's a tool that I use at my work with this purpose. That is why the DHCP server can't receive the broadcasts DHCPDISCOVER and respond with an DHCPOFFER message to the client, or at least that is what I thinks it's the problem. I really don't know why it's not maping the port UDP 67 from the container to the Host, this is as far i can go. Maybe it's this? At file Dockerfile.amd64: Only port 5380 and 53/upd are maped here.

Hi @dlandon, First, thank you for this plugin, to me is a must have, just in case someone, or myself, delete somethink we don't want to. Said that, and let me tell you that a I didn't read all pages of this thread, there are a few ..., there is a possibility to avoid that any user that have access to the share, delete files inside the bin? Only be able to see what inside (Read Only). An to delete the files do it from the plugin. This is to avoid that someone, with no good intentions, to delete some file completely, this functionality was used by my older NAS, a synology (bye bye forever, right now I hate that type of NAS, they are so bad compared to something like Unraid...), and was pretty useful and give higher security if the intention is to protect files from shares from unauthorized users that somehow access the share. Of course this is just an idea to further improve your plugin, it's ok if you see this idea a pain is the ... :P. Let me know your thoughts about this. Regards

Hi @Roxedus, After some research I decided to install this container to have an DNS with sinkhole capabilites and DHCP server in single container and not deploying a VM for that but I'm having problems with the DHCP server I deployed the container as Custom:br0 with custom IP 192.168.1.200 but after setting up the DHCP pool no device in my internal network is able to receive any IP configuration from the DCHP server. I tried to add UDP port 67 for the DHCP discovery just in case but it's not working. The DNS server is working without any problems as my internal DNS server but nothing to do with DHCP. I check the port 67 and it's closed/filtered. I'm a newbie with containers but maybe the container needs some modifications for the port 67? You can call me crazy or something worse but after more digging i saw that at the bottom of Dockerfile.amd64 there is a line that looks like "expose" ports for the container: EXPOSE 5380 53/udp, maybe can be changed to add port 67/udp and then DHCP will be accesible? Thanks.