Balor

Members
 View Profile  See their activity

  • Posts

    21

  • Joined

  • Last visited

Balor's Achievements

Noob

Noob (1/14)

4

Reputation

2

Community Answers

  1. Balor
    Changed Status to Solved
  2. Balor
    Confirmed working in 6.12.5 and 6.12.6
  3. Balor
    Fixed in 6.12.5 (and 6.12.6)
  4. Balor
    This has been opened for closed to a month. Any possible resolution ?
  5. Balor
    Hello, I've been trying for a while to mount a NFS drive on another server using NFS v4.2. And every time, it fallback to v4.0. This is really strange since the NFS server configured by Unraid has no issue talking in the v4.2 protocol. Example of mount command: root@Tower:~# mount -vvvv dolma:/Backs-Movies /tmp/test/ mount.nfs: timeout set for Tue Sep 12 21:01:32 2023 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.42.12,clientaddr=192.168.42.57' mount.nfs: mount(2): Invalid argument mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.42.12,clientaddr=192.168.42.57' mount.nfs: mount(2): Invalid argument mount.nfs: trying text-based options 'vers=4,addr=192.168.42.12,clientaddr=192.168.42.57' dolma:/Backs-Movies on /tmp/test type nfs (rw) I also tried with another server that I just configured NFS on, completely clean with Raspbian Bookworms. root@Tower:~# mount -vvvv vpn-mgt:/srv/test /tmp/test/ mount.nfs: timeout set for Tue Sep 12 21:14:18 2023 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.42.8,clientaddr=192.168.42.57' mount.nfs: mount(2): Invalid argument mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.42.8,clientaddr=192.168.42.57' mount.nfs: mount(2): Invalid argument mount.nfs: trying text-based options 'vers=4,addr=192.168.42.8,clientaddr=192.168.42.57' vpn-mgt:/srv/test on /tmp/test type nfs (rw,noatime) It looks like an oversight in either Unraid configuration of NFS Mount or missing kernel config or some issue in slackware ? It's hard to say what's the cause, since Unraid support v4.1 and v4.2 as a Server which lead me to think its configuration issue somewhere. I've asked for support to confirm the issue before opening this ticket.
  6. Balor
    I check with @dlandon and he came to same conclusion as me. The NFS Client of Unraid doesn't supports 4.1 and 4.2 only 3.0 and 4.0. I think that's a bug.
  7. Balor
    The weird part for me, it uses 4.0 for NFS Mount. But for NFS server, it supports 4.1 and 4.2. I wonder if it's a slackware bug/issue with their nfs client.
  8. Balor
    Hello, So I have another thread relating to NFS and the version supported by Unraid. In my test, it seems Unraid doesn't support version 4.1 and 4.2: I was suggested to check here if you would have more information. I'm not using UD to mount the NFS shares, I was debugging with good old mount command (since the NFS share are actually mounted using docker). Do I have an issue with Unraid misconfigured (v6.12.4) where the nfsmount don't support 4.1/4.2 or is it a feature not enabled ?
  9. Balor
    @itimpiI'm not using Unassigned devices, I'm using good old mount command. The /etc/nfsmount.conf is as it was setup by Unraid 6.12.4. I'm using docker container with volume that are on NFS drive, I prefer this than having to rely on UD to make the mount point in time for the docker container to use. The version supported by NFS on Unraid is the responsability of LimeTech since those are either kernel config or package configuration.
  10. Balor
    Hello, I've been trying for a while to mount a nfs drive on another server using nfs v4.2. And everytime, it fallsback to v4.0. This is really strange since the NFS server configured by Unraid has no issue talking in the v4.2 protocol. Example of mount command: root@Tower:~# mount -vvvv dolma:/Backs-Movies /tmp/test/ mount.nfs: timeout set for Tue Sep 12 21:01:32 2023 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.42.12,clientaddr=192.168.42.57' mount.nfs: mount(2): Invalid argument mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.42.12,clientaddr=192.168.42.57' mount.nfs: mount(2): Invalid argument mount.nfs: trying text-based options 'vers=4,addr=192.168.42.12,clientaddr=192.168.42.57' dolma:/Backs-Movies on /tmp/test type nfs (rw) I also tried with another server that I just configured nfs on, completly clean with Raspbian Bookworms. root@Tower:~# mount -vvvv vpn-mgt:/srv/test /tmp/test/ mount.nfs: timeout set for Tue Sep 12 21:14:18 2023 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.42.8,clientaddr=192.168.42.57' mount.nfs: mount(2): Invalid argument mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.42.8,clientaddr=192.168.42.57' mount.nfs: mount(2): Invalid argument mount.nfs: trying text-based options 'vers=4,addr=192.168.42.8,clientaddr=192.168.42.57' vpn-mgt:/srv/test on /tmp/test type nfs (rw,noatime) And if I mount the same share from other machine, no issue using the v4.2 protocol. I'm at a loss, I don't understand why Unraid can't use that protocol for NFS mounts.
  11. Balor
    Thanks, confirmed, newest update of Connect fixed it.
  12. Balor
    The editor of the compose file stopped working for me. I'm getting this error in the browser console. TypeError: ace.edit is not a function editComposeFile http://tower/Docker:1819 c http://tower/webGui/javascript/dynamix.js?v=1680052794:5 fireWith http://tower/webGui/javascript/dynamix.js?v=1680052794:5 l http://tower/webGui/javascript/dynamix.js?v=1680052794:5 o http://tower/webGui/javascript/dynamix.js?v=1680052794:5 lockdown-install.js:1:103865 functors moz-extension://6e8b3f5f-5e69-4f16-bccf-ffea1fe4a2d1/lockdown-install.js:1 It seems the ace editor isn't there anymore, I haven't done anything other than updating Unraid connect ...
  13. Balor
    Well in the end it was a hardware issue, the memory was failing. Replace those stick by good ones from corsair and since that, no more issues. The previous stick looks like they were overheating (I can see the temp of the server have drastically reduced since I replaced them).
  14. Balor
    After trying everything, I simply rolled back the latest container I had setup : https://github.com/thrnz/docker-wireguard-pia Using docker container that redirect their traffic to an other causes my stability issues. Once I removed this container and the network setup, everything is table again.
  15. Balor
    In my setup I narrowed down the docker crash to a container that did interact with the network layer. I'm using 6.12.1 with ipvlan. https://github.com/thrnz/docker-wireguard-pia The idea is to tell other containers to use this one for their network. This container act as a VPN router that redirects the traffic to Private Internet Access. As soon as I removed it, my server is fully stable again. So my guess is, there is some issues with stability and networking. To be clear I had those issue already in 6.11.5, so I think there is some underlying issue in docker network. Weirdly enough, if I use a container that has built it wireguard capabilities, it just work and the server stay stable.