dlandon

Remove UD and see if the situation changes.

Do you have the latest version of UD installed? I recently made a change. Also check the log. It may show a message suggesting a reboot to finish removing the partition.

Did you type 'Yes' with a cap 'Y'?

What flag? Your log is so full of these messages, I can't read it: Dec 6 04:43:45 WAMRED autofan: Highest disk temp is 40C, adjusting fan speed from: 126 (49% @ 819rpm) to: FULL (100% @ 828rpm) Can you stop the autofan messages?

Working fine for me, but I don't use swag. Be careful with the auth hash. There is an option to include the IP address in the hash and that might be your issue. BTW, the ZmNinja app is suooprted. It's the event server that is no longer supported. That being said, it does work and I'm using it with ZmNinja.

There is no spin down control on UD devices. The best way to do this is to set the global spin down to never spin down disks, then set a spin down on the disks you want to spin down.

You are posting in the UD preclear forum. Auto mounting of a precleared drive doesn't make any sense because there is no file system and never will be. Once a drive has a file system, it will no longer show as a preclear candidate on the preclear page and will show on the UD page.

The drive cannot be auto mounted because there is no file system after being precleared.

It looks like you have your Unraid shares set to 'Public'. Microsoft has changed access to Public shares. I can't remember where in the Forum this is talked about, but you'll have to make some changes to Windows clients to access Public shares. Not sure about Mac computers.

I doubt this will help because the issue is not showing up on Unraid. This solution was a "get around" for NFSv3 server issues on Unraid. Try adding 'noacl' to the mount paramaters. Also check your mount setup. I don't think you are mounting using NFSv4. The experience we've had on Unraid is that just using the NFSv3 server on Unraid caused the stale file handle situation. Once we converted to NFSv4, the stale file handle issue went away. If the stale file handle issues you are seeing are not showing on Unraid, there probably isn't much more we can do to help you. You'll have to look on the client side to see what is happening.

That is not reflected in the latest survey here. AD is not an important feature according to the users responding in the survey. You'll see it as the second from the bottom in importance.

This is why just changing the backend to tdb is not an easy solution. It will break existing permission settings.

We appreciate the level of frustration that the AD issues are causing. We are paying attention to the feedback we are getting. AD is an enterprise feature that was added many years ago at the request of a user. It was fairly simple to implement and was added to Unraid. Over the years there have been changes made and Unraid did not keep up with those changes - e.g. the idmap backend. Changing the backend is not as simple as just changing one setting. Our research has shown there is more to it than that. We don't want to create more problems than we fix. AD is not a main stream Unraid feature and unfortunately, doesn't get the attention that users expect. It is noted in our system as an issue, but is not a high priority at this point because it doesn't affect as many users as other issues.

Help me understand, everytime you run CrashPlan backup you run into the 65535 files open limit? It backs up that many files every time?

Where are you seeing stale file handles? There aren't any logged in the syslog.

I see some issues that might not be related, but should be worked on: Your network.cfg has some strange settings that look to be from older Unraid versions. Delete the /flash/config/network.cfg and reboot. This will regenerate the default network settings. Then go to Settings->Network and review and re-apply settings. Your settings shows that you have NICs bonded, but the NICs are not specified, and the settings to set that is not right. Set your docker custom network to ipvlan and not macvlan. The reason I'm bring this up is your log is full of this: Dec 6 04:41:02 TC kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethe2c505e: link becomes ready Dec 6 04:41:02 TC kernel: docker0: port 1(vethe2c505e) entered blocking state Dec 6 04:41:02 TC kernel: docker0: port 1(vethe2c505e) entered forwarding state Dec 6 04:41:02 TC kernel: docker0: port 1(vethe2c505e) entered disabled state Dec 6 04:41:02 TC kernel: veth99c83b2: renamed from eth0 Dec 6 04:41:03 TC kernel: docker0: port 1(vethe2c505e) entered disabled state Dec 6 04:41:03 TC kernel: device vethe2c505e left promiscuous mode Dec 6 04:41:03 TC kernel: docker0: port 1(vethe2c505e) entered disabled state Dec 6 04:42:02 TC kernel: docker0: port 1(veth9a08ef2) entered blocking state Dec 6 04:42:02 TC kernel: docker0: port 1(veth9a08ef2) entered disabled state Dec 6 04:42:02 TC kernel: device veth9a08ef2 entered promiscuous mode Dec 6 04:42:02 TC kernel: docker0: port 1(veth9a08ef2) entered blocking state Dec 6 04:42:02 TC kernel: docker0: port 1(veth9a08ef2) entered forwarding state Dec 6 04:42:02 TC kernel: docker0: port 1(veth9a08ef2) entered disabled state Dec 6 04:42:04 TC kernel: eth0: renamed from veth56aaa31

Post your diagnostics file. I may have some ideas to try.

The docker script is not the same script as the plugin. What parameter did you have to pass and how did you do it? Post your server diagnostics.

You're doing something to stop the preclear. The message "Preclear stopped on device:..." only occurs from an operator action.

Set up the syslog server to save the syslog, reboot the server with the drive set to not auto mount, then go to UD and mount the drive. Post the syslog. I think your drive is hanging UD with something and the syslog should show what is hanging. An alternative is to try another drive.

Remove everything from smb-extra.conf and turn on the "Share" switch in the drive settings - the double gear icon on the disk on the UD page. Go to the UD settings and set SMB Security the way you'd like for UD devies. You can't set share settings in smb-extra.

Did you install UD and not mount the drive as a test? UD queries the drive after it is mounted to get stats and that might be the issue. Manually mounting the drive is fine, but UD wouldn't be running to query the disk.

The plugin is not buggy. I works very well for many people. The docker is an option and if it worked for you, that's great.

Or your backup program is opening them and not closing them? Why does your backup program run 4-6 hours? It copies every file on each backup? Doesn't sound like an incremental backup to me. I'd talk to the authors of CrashPlan and ask them how their backup works and if it's possible that it is not closing files.

Set your docker network to ipvlan and not macvlan.