Kir

I think I found a bug in this release. I have a custom network set up for some of my docker containers, and after upgrade they became unreachable, although kept communicating to each other. In the past their traffic went through unraid default gateway. It does not work in 7.3.0, and the only way to make them work was to add another DG just for that network like so:

I myself ended up running "New Permissions", as the current ones didn't work after upgrade on many shares.

I take it you checked the permissions on the shares? What worked on previous versions, sometimes doesn't on a newer ones. Multiple threads on this.

The reason is that the newer versions of unRaid have NFS UDP disabled by default, only NFS TCP works. Here is the solution to bring it back:

Here is the solution from my friend @halfelite <-- BIG thanks! File /etc/default/nfs needs to be modified to add the following line: RPC_NFSD_OPTS="-u" This would enable NFS UDP back. To make it survive the reboot, add the following line to the go file: echo "RPC_NFSD_OPTS=\"-u\"" >> /etc/default/nfs

I think I found the reason, and it has nothing to do with NFS V3 vs V4. This is what the NFS on unRaid 6.11 looks like: # rpcinfo -p | grep nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs There is no NFS over UDP anymore. And PCH A500 connects via UDP by default. Is there any way to enable it?

The rule is set as described above: Security: Private Rule: *(ro,insecure) Remote client is PCH A500. I suspect it doesn't like NFS V4...

Apologies, that was the wrong file. I used it to show the 2nd parity issue. Please find below as requested. exportfs -v shows all is well, however remote client cannot access it anymore. As soon as I downgrade to 6.9.2, all works again. storage-diagnostics-20221126-1559.zip

Here it is (ignore the 2nd parity drive, it's a separate issue) storage-diagnostics-20221112-1143.zip

Well... I just found that 6.9.2 had NFS V3, while 6.11.2 has V4. Could it be the reason why clients cannot access it now?

Anyone?

Hi guys, I upgraded from 6.9.2 to 6.11.2, and lost access to my NFS shares. Somewhere along the way something got changed, and my current config no longer works. I have the shares exported as: Security: Private Rule: *(ro,insecure) It worked in 6.9.2, and became inaccessible in 6.11.2. After reverting back to 6.9.2 everything worked again. Could you tell me what changed and how to fix it in the newer versions? Thank you!

Well... not really. It got disabled when I updated to 6.11.2, I just rebuilt it, and after 6.11.3 upgrade it got disabled again. I don't really see any indication why. Do you?

Upgraded, and 2nd parity drive shows up as disabled. Diagnostics attached below. storage-diagnostics-20221112-1143.zip

Upgraded from 6.9.2 to 6.11.2. Upon startup second parity disk got disabled. No errors in syslog. Ran a quick test - all OK. Rebuilding now. Weird...

I still have a doubt that is how it works. After reinstalling with the new template, I got another public IP from my provider, but the old one still shows as open on the same port. Several addresses "around" the one I got also show up as open...

So... what's the safe way to delete or reinstall with the new template? I do know it came from the times I started using Deluge long time go.

Shows "port is open". Does it mean it is correctly forwarded to my local Deluge, or it's just in a listening state by the VPN provider? Host Port 3 and Host Port 4 both contain the parameters for "Container Port: 58946" Container Variable: VPN_REMOTE and Container Variable: VPN_PORT - I cannot blank it out. I don't think it's needed for ovpn files. Thank you!

Hi guys, I recently switched to the latest version of Deluge, and to the VPN. Everything seems to be working, albeit slow. Now I have more questions than ever before: 1. How to I check that the port forwarding works? 2. I assumed that I put the port number given to me by the VPN provider into the Deluge UI incoming port field, the one that had "58946" by default. Is it correct? 3. Do I need to punch any holes in my firewall to allow port forwarding over VPN to work? 4. The log file contains something strange: Fri Mar 6 09:23:11 2020 UDP link local: (not bound) Fri Mar 6 09:23:11 2020 UDP link remote: [AF_INET]n.n.n.160:1302 but Deluge UI shows my external IP as n.n.n.164 5. And finally, there are many parameters for the docker that either came from the old version, or duplicates (?). Which ones are required, and can I remove the rest? Thank you!

Rolling back to 1.3.15_18 fixed the issue. PS: In my case, it's secure enough - I only allow socks connections from that host. This is how I found out it broke

Correct 2019-09-06 10:58:02.532672 [info] VPN_ENABLED defined as 'no' 2019-09-06 10:58:02.562400 [warn] !!IMPORTANT!! VPN IS SET TO DISABLED', YOU WILL NOT BE SECURE

My VPN provider does not allow port forwarding, so Socks5 through them is the only option.

Well... it kind of worked with the previous release. Now it doesn't even try to connect on 1080...

Hi, It looks like the latest version of Deluge ignores the proxy settings. I've always had it set up with Socks5 auth to port 1080, and now it just totally ignores it. Is it a known issue?

Updated no problem, clean syslog, server layout does work in this version