stayupthetree

Did this resolve the watchdog issue and becoming unresponsive? this has happened to me every day the last 4 or 5 days. I dont have anything being passed through. Fortunately I have a KVM and can safe shutdown, but Im losing my mind doing this every day.

The File Descriptors worked thanks!

Currently it is showing (null) could that be part of it??

I don't know what changed, but I can't connect to my Unraid NFS shares any more. I attempted to restart and it fails. The logs show Jan 19 11:31:30 Star-Labs rpc.mountd[118572]: Unable to initialise v4clients watcher: Too many open files Jan 19 11:31:30 Star-Labs rc.nfsd: NFS server daemon... Failed. tail: inotify cannot be used, reverting to polling: Too many open files The last line is from when I tail the log files. So I thought maybe it was an inotify issue. I researched and saw to install Tips and Tweaks. I doubled my watches, nadda star-labs-diagnostics-20250119-1103.zip

I know this is old, but I wanted to thank you for this answer! After much banging of the head against this issue, this is the first page on the internet I came across with a clear answer to to fix my NFS permission issues.

no ipv6 here, just ipv4 from the br0 network

AdGuard container fails to start with the following error "DNS Resolution Error. Start the container with --dns=1.1.1.1 or 8.8.8.8"

Do you advertise the subnet or have Allow Local Network Access enabled?

I suspect it has to do with the "none" and it having a "null" network. Not sure how it was created but default if you do something like "docker network create the_arrs" is bridge. just did it here. Id create the network and point the container to it Looked at my configuration and none is something already setup by Unraid/Docker, so you just need to change your network off it to get an IP

Settings page is blank for me

How will this affect LXC in Unraid? https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479

Everything I've found on the topic was related to docker, but as you can see from the losetup output it isn't listed. Everything else I found on the topic that was an issue that was fixed? NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 1 1 /boot/bzfirmware 0 512 /dev/loop0 0 0 1 1 /boot/bzmodules 0 512 root@Tower:~# tail -F /var/log/syslog Apr 3 19:57:23 Tower emhttpd: Unmounting disks... Apr 3 19:57:23 Tower emhttpd: shcmd (274): /usr/sbin/zpool export cache Apr 3 19:57:23 Tower root: cannot unmount '/mnt/cache': pool or dataset is busy Apr 3 19:57:23 Tower emhttpd: shcmd (274): exit status: 1 Apr 3 19:57:23 Tower emhttpd: Retry unmounting disk share(s)... Apr 3 19:57:28 Tower emhttpd: Unmounting disks... Apr 3 19:57:28 Tower emhttpd: shcmd (275): /usr/sbin/zpool export cache Apr 3 19:57:28 Tower root: cannot unmount '/mnt/cache': pool or dataset is busy Apr 3 19:57:28 Tower emhttpd: shcmd (275): exit status: 1 Apr 3 19:57:28 Tower emhttpd: Retry unmounting disk share(s)... Apr 3 19:57:33 Tower emhttpd: Unmounting disks... Apr 3 19:57:33 Tower emhttpd: shcmd (276): /usr/sbin/zpool export cache Apr 3 19:57:33 Tower root: cannot unmount '/mnt/cache': pool or dataset is busy Apr 3 19:57:33 Tower emhttpd: shcmd (276): exit status: 1 Apr 3 19:57:33 Tower emhttpd: Retry unmounting disk share(s)...

default appsettings.json is blank

react resume server is a bust, sometimes I dont think people go through the setup process themselves before pushing an application through

I have a small compose stack setup and it working great for the most part. Problem is every night when I do a backup of my standard unraid docker containers, the stack is restarting. I've gone into the specific plugin and set the containers made from the stack to be skipped, which setting skip works for the standard unraid docker containers, but the stack keeps restarting every night. is there something somewhere I am overlooking causing this???