Alacard

nope never found out what the problem was or how to fix it, i took the extreme option and nuked all my containers and readded them, been fine since then P.S. i also changed my "Docker custom network type" to macvlan from ipvlan (Settings -> Docker -> Enable advanced view)

Had to reorder them a few time but it seem to fixed them self's after about the 3rd reorder

Dont seem to be working for me, the items that are showing for the folders i created are all wrong. debug-DOCKER.json

@Tomo82 sorry for the semi late reply, yes im still using it currently running 6.12.0-rc2

Welp nope that didnt fix it, just did it again here's the new logs media-server-diagnostics-20220602-1924.zip

after much digging, i think i may have found the problem, i had a docker that "network" that was host, and had another docker that was on a custom network. the docker thats on the host network was created first. and then made the docker thats on the custom docker a few days later, for some reason i didnt get a error message when unraid created the 2nd docker saying that a port was already in use.(the first docker was already using the port 1900) so with both dockers running. i believe thats why i keep getting the error message "kernel: TCP: request_sock_TCP: Possible SYN flooding on port" right before it start acting up. So far (knock on wood) seems to be working since i made that fix (been 2 1/2 hr's so far) edit: both dockers was created back in 6.9.2

Welp that didnt take to long, tryed pinging 8.8.8.8 but no reply root@media-server:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. From 192.168.1.254 icmp_seq=1 Destination Host Unreachable From 192.168.1.254 icmp_seq=2 Destination Host Unreachable From 192.168.1.254 icmp_seq=3 Destination Host Unreachable From 192.168.1.254 icmp_seq=4 Destination Host Unreachable From 192.168.1.254 icmp_seq=5 Destination Host Unreachable From 192.168.1.254 icmp_seq=6 Destination Host Unreachable From 192.168.1.254 icmp_seq=7 Destination Host Unreachable From 192.168.1.254 icmp_seq=8 Destination Host Unreachable From 192.168.1.254 icmp_seq=9 Destination Host Unreachable From 192.168.1.254 icmp_seq=10 Destination Host Unreachable here's the new logs media-server-diagnostics-20220528-1301.zip Edit: From looking at the log it looks like ipv6 is the problem, IPv6 is getting assigned to veth1ed7c5b despite having the server set to ipv4 only (Registering new address record for fe80::494:84ff:feb1:69d8 on veth1ed7c5b.*) just my 2 cents. Edit2: just checked to make sure, ipv6 is disabled on the router so no sure where its getting the ipv6 from

For some reason unraid keeps losing internet access randomly. this all started around 6.9.2 (currently running 6.10.2). i quickly found out that if i stop the docker service (Settings -> Docker -> Enable Docker -> No) unraid will get internet access back again. but as soon as i enable docker back it becomes a ticking time bomb, until it losses internet again. Know from what i have tryed will the unraid is unable to access the internet. is that im still able to access the GUI and able to telnet to it and also able to ping the router/dns server from the server just fine (192.168.1.1) but anything having to do with the net is dead no reply (8.8.8.8,1.1.1.1,google.com). after hoping that a update may fix the problem im having, and seeing as it did not. im finally decided to ask for help media-server-diagnostics-20220528-1139.zip

yes, im currently running 6.10.0-rc3 and still working

Changed Status to Closed

First of all im new to unraid, coming from a qnap nas, one of the feature that i found out unraid didnt support was "Home" shares. What that feature is, a share called "homes" and every user gets there own subfolder in that share that only they can access. seeing that all my users use this as a remote storage for Docs, Pics, etc. and just mapped the folder to windows to use. this is one feature i could not go with out. so Ive made some "tweaks" to unraid to be able to have this feature and wanted to share my findings for anyone looking for something like this. need less to say, im not responsible for any data loss thats up to you to take the risk. 1) Create a share called "homes" (NOTE: with a 's')and set the export to "no" security to "Public and leave everything else to default 2) create a directory under "/mnt/user/appdata" called "home" (NOTE: without the 's') 3) goto the directory created in the last step ("/mnt/user/appdata/home") and create a file called "create_userdir.sh" and set permissions to 777 (there maybe a more secure way to allow this script to run but this worked for me). 4) open the file created in the last step ("create_userdir.sh") with a editor then copy, paste, save the code below #!/bin/sh USER="" if [ $# -gt 0 ]; then USER=$1 fi if [ $USER ]; then if getent passwd | grep -q "^$USER"":"; then if [ ! -d "/mnt/user/homes/$USER" ]; then mkdir -m 777 "/mnt/user/homes/$USER" chown $USER:100 "/mnt/user/homes/$USER" exit 0 else exit 0 fi else exit 1 fi else exit 1 fi 5) Mount your usb boot drive and open "/config/smb-extra.conf" then copy,paste,save the code below (make sure you paste the code AFTER anything thats already in that file. DO NOT delete/overwrite anything there) #Home_Start [home] comment = Home path = /mnt/user/homes/%U browsable = yes invalid users = guest writable = yes read list = "%U" write list = "%U" valid users = "%U" root preexec = /mnt/user/appdata/home/create_userdir.sh '%U' #Home_Stop 5b) when you done it should look something like this 6)reboot & profit you will see a new share called "home" Ok here the break down of what this do.... smb-extra.conf creates a dynamic share called "home" when a user trys to access the share "home" a script called 'create_userdir.sh' is ran what "create_userdir" do is, take the username that is trying to access this and check if there "private" directory already exist and if not create the directory (this is for when a new user is create and dont already have a "private" directory, its to make sure that the share "home" have a valid directory to be mounted to) smb-extra.conf then dynamically sets the path to what ever the current user "private" directory is. because of how the shares works per user. your only able to see YOUR "private" share. If an admin wants to make changes or delete some files thats not theirs they can go to "/mnt/user/homes/" to see all the users "private" directory. Hope this helps someone, and feel free to leave a reply if you need some help.

For Web access using http://192.168.1.200:8112 but for the daemon via 58846 i use deluge gui connection manager to connect to it For the run command.. If you talking about the command it use when starting the container its "/usr/bin/tini -- /bin/bash /root/init.sh" but if you talking about the command it use when making the container for the first time. not sure on that one i maybe able to track that down by checking the logs Edit: OMFG... found out the problem... for some reason qnap made a bridge with the subnet of 255.255.0.0 -.-, so i just corrected the subnet (255.255.255.0) in the config file and restarted docker/container. just sent them a bug report that its overwriting the settings you set with a default subnet of 255.255.0.0 on container creation. Sorry for wasting your time like that >.<

Dont know what fixed the problem with OpenVPN closing (rebooted everything nas,modem,router,switch) but that some how fixed itself. now ive ran in to another problem, i cant access deluge from web access or from daemon via 58846. So started troubleshooting. Made sure the subnet was set right (192.168.1.0/24) and it is. So ran a port scan to make sure the ports are even open via nmap a, came back with 8112/tcp open unknown 8118/tcp open privoxy? 58846/tcp open unknown So ports are open, started to wonder if that was privoxy or deluge opening the ports so checked deluge config and it listen interface is set to 10.4.90.199 (vpn ip) so got to wondering if deluge is set to use vpn ip then privoxy is forwarding local ip traffic to the ip... checked to make sure that what was happening via ipconfigs --list, it came back with Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- 192.168.0.0/16 192.168.0.0/16 ACCEPT udp -- anywhere anywhere udp spt:https ACCEPT tcp -- anywhere anywhere tcp dpt:8112 ACCEPT tcp -- anywhere anywhere tcp spt:8112 ACCEPT tcp -- 192.168.1.0/24 anywhere tcp dpt:58846 ACCEPT tcp -- 192.168.1.0/24 192.168.0.0/16 ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- 192.168.0.0/16 192.168.0.0/16 ACCEPT udp -- anywhere anywhere udp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:8112 ACCEPT tcp -- anywhere anywhere tcp spt:8112 ACCEPT tcp -- anywhere 192.168.1.0/24 tcp spt:58846 ACCEPT tcp -- 192.168.0.0/16 192.168.1.0/24 ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT all -- anywhere anywhere Nothing was being forwarding. at this point i ran into a dead end. as a lost desperate attempt i checked deluge log and that really got me confused, some how my pc (192.168.1.250) was trying to connect and deluge shows that but the connection being dropped it seems. [INFO ] 09:48:56 configmanager:70 Setting config directory to: /config [INFO ] 09:48:57 daemon:127 Deluge daemon 1.3.15 [INFO ] 09:48:57 configmanager:70 Setting config directory to: /config [INFO ] 09:48:57 core:87 Starting libtorrent 1.0.9.0 session.. [INFO ] 09:48:57 rpcserver:369 Starting DelugeRPC server :58846 [INFO ] 09:48:57 core:97 *** Start Label plugin *** [INFO ] 09:48:57 pluginmanagerbase:158 Plugin Label enabled.. [INFO ] 09:48:57 pluginmanagerbase:158 Plugin AutoRemovePlus enabled.. [WARNING ] 09:49:02 core:131 check interval loop starting [INFO ] 09:49:40 rpcserver:206 Deluge Client connection made from: 192.168.1.250:65128 [INFO ] 09:49:42 rpcserver:206 Deluge Client connection made from: 192.168.1.250:65129 [INFO ] 09:49:59 rpcserver:226 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [INFO ] 09:50:01 rpcserver:226 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [INFO ] 09:52:18 torrentmanager:737 Saving the state at: /config/state/torrents.state [INFO ] 09:55:38 torrentmanager:737 Saving the state at: /config/state/torrents.state [INFO ] 09:58:58 torrentmanager:737 Saving the state at: /config/state/torrents.state [INFO ] 09:59:43 rpcserver:206 Deluge Client connection made from: 192.168.1.250:65258 [INFO ] 09:59:45 rpcserver:206 Deluge Client connection made from: 192.168.1.250:65261 [INFO ] 10:00:02 rpcserver:226 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [INFO ] 10:00:04 rpcserver:226 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. Here's a new log file. i hate to keep bugging you, hope you dont mine deluged.log supervisord.log

Ive add pull-filter ignore "route-ipv6", pull-filter ignore "ifconfig-ipv6" to vpn config file thinking that was it because of this error message "Linux route add command failed: external program exited with error status: 2" (that didnt work) but other then that i dont see anything else that would apply to me from the FAQ. Here a new log with debug set to true supervisord.log

Ive been using your DelugeVPN Docker for about 8-9 months, When i notice that none of the torrents was downloading. So checked console, and for some reason VPN keep connecting & disconnecting. I seen that i was running a outdated version (Deluge was 1.3.14 or 1.3.13 cant remember), thinking that maybe the problem (a bug with that version that i have not experienced before now?) So i took screenshots of Docker conf., removed docker and reinstall with the newest version (1.3.15+2+g38d7b7cdf-1-12) reentered all config setting. And started docker UP. Same thing VPN keeps connecting then disconnecting. but this time i cant even connect to deluge webui (i was able to before the upgrade even with vpn acting up). So maybe that VPN Server acting up? tryed 3 more servers (endpoints) still the samething even tryed 2 more servers with different ports (was using 433 so tryed 53, 1194) I'm a (mid grade) noob when it comes to linux/docker so that was all the basic troubleshooting i did. Im hoping you can help me out. Server Notes Running on Qnap 4.3.4.0370 Build 20171103 Bridge Mode Container ip/subnet 192.168.1.200/255.255.255.0 Run container in privileged mode = Checked (was the only way i could get docker to work in older version) supervisord.log