kubed_zero

@Dro I've been unable to reproduce the issue. I suspect it has something to do with your network configuration messing up the self-test at plugin install time, but I'm not positive. Perhaps it would be helpful to fully delete the files associated with SNMP on the boot drive? - the /boot/config/plugins/snmp folder, which contains an snmp.conf if defined, as well as the .txz files - the /boot/config/plugins/snmp.plg file

Yeah, this could definitely be the case. I agree completely that Apple could be going off the rails in how things are built. But considering upgrading the server causes the breakage while the Apple device stays the same, and the Time Machine functionality in Unraid is built exclusively for Apple devices, I would have hoped that Limetech could have pinned the Samba version on something functional (or at least tested it in 6.10 to a thorough degree). It's not a good look for Limetech if upgrades to 6.10.x result in failures of core functionality such as the built-in Time Machine backups, and then a reversion to the previous stable release can fix any issues seen. That's just my two cents, though I think I'm not alone in that sentiment. At some point in the next few weeks I'm going to try experimenting with installing 6.10.3 and then modifying my Go script to: Stop the Samba process, I think with "/etc/rc.d/rc.samba stop" Install the Samba version from 6.9.2 and hopefully overwrite the default version. I found 6.9.2 used version 4.12.14, as opposed to 4.15.7 in 6.10.3 Start the Samba process, I think with "/etc/rc.d/rc.samba start" See if initial and then incremental backups still work I'd also want to try rolling forward and seeing if Samba 4.16.x packages would work, which should be straightforward to test once this Go script stuff is in place. If anyone else gets a chance to do this, please share your results! It will be curious to see if the Samba package upgrade broke the functionality between 6.9 and 6.10, or if it was kernel-related modification, or something else.

I'm not sure I follow. If that were the case, why (in my setup) does upgrading to 6.10.x break backups, but reverting to 6.9.2 100% of the time fix backups? Yep, I wanted to avoid going back to using an AFP share because of Apples deprecation of it.

Nope, I think only you (as the issue creator) and admins have that ability

Eh, my opinion is that if Limetech includes the feature in the base OS, it should work properly and not break on a version upgrade. Perhaps this is a result of updating the Samba package, and not a kernel update issue. We'll have to do more testing to evaluate what broke it. Anyway, I don't want to run Docker on my NAS (would prefer a separate system considering Unraid is already a VM on my ESXi cluster) so I'll just stick on 6.9.2 until the built-in feature works again

I'm going to give this a shot, since there's nothing in 6.10.x that is beneficial to me. Will report back. Yep this worked 100%. All Macs, M1/Intel, are backing up successfully to preexisting and new backups on a single Time Machine Unraid share now that I've downgraded to 6.9.2 from 6.10.3. Unfortunate that this is necessary, hopefully @limetech will reopen these bugs and investigate further. So just to summarize: Unraid 6.10.3 uses smbd version 4.15.7, while Unraid 6.9.2 uses smbd version 4.12.14 (checked with "smbd --version") All other SMB-related configs seem identical, such as /etc/samba/smb-shares.conf, /etc/samba/smb-names.conf, /etc/samba/smb.conf, and *a lack of* /boot/config/smb-extra.conf (meaning no SMB Extras defined) Time Machine backups proceed normally on Unraid 6.9.2 from both Intel and M1 Macs running MacOS 12.4, while the same incremental backups fail on Unraid 6.10.3 with a Console log Mac-side along the lines of "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading} The below SMB Extras config added to 6.10.3 allowed some but not all Macs to back up. Removing it caused then-working Macs to start failing again. [Global] vfs objects = catia fruit streams_xattr fruit:nfs_aces = no fruit:zero_file_id = yes fruit:metadata = stream fruit:encoding = native spotlight backend = tracker The below SMB Share config is the Time Machine destination on 6.9.2 and 6.9.3, which houses ALL Macs' backups (despite the instruction in https://wiki.unraid.net/UnRAID_6/Configuring_Apple_Time_Machine to have one backup per share, which seems to be bad advice): [TimeMachine] path = /mnt/user/TimeMachine comment = browseable = yes # Private writeable = no read list = write list = backup valid users = backup vfs objects = catia fruit streams_xattr fruit:time machine = yes fruit:time machine max size = 1200000M case sensitive = auto preserve case = yes short preserve case = yes I also keep my Time Machine share constrained to a single disk, as I've had cross-disk issues in the distant past

Eh... neither of those are acceptable solutions in my mind. The out of the box Time Machine functionality should work without a need for a third party solution, and reinstalling MacOS after just having done so in the past month also seems less-than-ideal. I'm going to give this a shot, since there's nothing in 6.10.x that is beneficial to me. Will report back.

Wanted to share that the other recent thread concerning this issue helped me out, I was able to add some SMB Extra Settings and that seems to have fixed the problem for at least one of my Macs. The issue doesn't seem to be fully resolved though.

Just wanted to say I had this issue on both Intel and M1 Macs. Time Machine backups to Unraid were going swimmingly, with the Unraid share hosting an APFS sparseimage. I'm not sure if it was the Unraid 6.10 update or MacOS 12.3/12.4 or just bad timing, but then all the computers stopped being able to back up a month or so ago. I was able to make first (non-incremental) backups without issue, but subsequent incremental backups after that did not work. I had the same MacOS console issues as mentioned above: "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading} I had tried deleting the local snapshots on each Mac as well, to no avail. For reference, that's "tmutil listlocalsnapshots" to find the snapshot names and then "tmutil deletelocalsnapshots <snapshot-name>" to actually delete them. Anyway, I applied the SMB Extra Config settings as mentioned above, and then re-attempted the incremental backups. Success! (Update: Time Machine now works on two of the three Macs. The last one still gets the "Failed opening folder for entries reading" error) The following SMB Extras config seems to have done the trick: [Global] vfs objects = catia fruit streams_xattr fruit:nfs_aces = no fruit:zero_file_id = yes fruit:metadata = stream fruit:encoding = native spotlight backend = tracker I did browse through the documentation pages to understand what these were doing https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html and the only callout I have is that the zero_file_id setting is yes by default, and may not be necessary. The rest of the options check out, though I'm not sure why this combination of options makes Time Machine work. I saw another post say that just setting two of these worked: As a sidenote, I DID see that https://wiki.unraid.net/UnRAID_6/Configuring_Apple_Time_Machine recommends having a separate share per computer, but that seems to be outdated (bad?) advice and perhaps should be changed. I've got three Macs backing up to the same Time Machine share with no issues.

All right folks, I just updated to 6.10 on my existing install (no Docker or any fancy stuff) and SNMP installed after reboot without any issue. I'll have to give a vanilla install + reboot a shot on a spare flash drive, but I suspect that will yield the same no-issue result. I'll report back if I see anything otherwise. In the meantime, please let me know if reproduction steps are available on a fresh install for this SNMP not installing after reboot issue. Thanks!

Right, that's why the dependencies are cached to USB on first install, so the SNMP plugin still installs even if the network isn't up on future boots (for example if someone runs pfSense as a VM on their Unraid box). I was under the assumption that localhost/127.0.0.1 would be guaranteed to exist by the point in the boot process that Unraid does plugin initialization, and that regardless of network hardware, localhost would always exist (since I'd expect the WebGUI to also depend on it). Is there documentation that could confirm or deny this? I'm also open to suggestions for how to do a validation that SNMP is functioning correctly without relying on the network, but I don't have any ideas at the moment.

If anyone's able to provide reproduction steps from a clean install of the latest 6.10 RC, let me know and I will investigate. Otherwise, it has been very difficult to evaluate what's going on. I had no issues on a clean install and wasn't able to reproduce, and SimonF also mentioned not being able to reproduce as of 6.10-RC3.

Thanks for reporting back! I gave it a shot in my test UnRAID virtual machine on the latest RC, which as of writing is 6.10.0-rc2. I did not experience any issues, SNMP installed on boot as expected. Here's what I did: - Prereq: NerdPack already installed, and I don't have any disks or a license so this is is without the array starting. - Install SNMP 2021.05.21 and copy the logs of the popup window - Shut down Unraid - Boot up Unraid (again, the array doesn't start, but that doesn't matter anyway since plugins install before mounting the array I think) - Go to the Plugins tab and see SNMP among the Installed Plugins - Go to the Tools > System Logs page and copy out relevant information, such as the NerdPack install and the SNMP install logs. Here are those logs: https://pastebin.com/r6mKqEYT Can you do the same for your installation? I wonder if there's something going on with NerdPack or your prerequisite packages that is preventing install on boot.

Thanks for chiming in, I'm in the same boat. Haven't tried the 6.10 releases yet so yeah, maybe something with that. I also remember the plugin being in a certain state during development where it would fail to install if the dependency packages weren't cached on the boot drive AND the network wasn't yet available at boot time, though that issue was fixed. The plugin also checks to make sure it's working and fails the install otherwise (the PLG file defines this behavior) so maybe there's something with 6.10 or with @BigJuanKer 's system that is preventing SNMP from working correctly at boot. I guess we'll see soon!

Does the plugin show up in the "Plugin Install Error" or whatever the tab is named, next to "Installed Plugins" and "Install Plugins?" If a plugin fails to install at boot up, that's where it ends up. I wonder if there's a race condition occurring at boot time that prevents the plugin from installing.

My suggestions would be checking the logs (of course), also trying rebooting, or removing any SNMP-related files from your boot USB. You can also see if the SNMP service is still running when it "stops responding" and one other suggestion might be to call SNMP from Unraid itself (the install script does this so you can reference it for syntax) One final suggestion is to remove the custom script extensions from the SNMP config so it's not checking disk temps and just reporting basic Linux stuff. Maybe something there is causing an issue, not sure.

1 seems a bit complicated for what is essentially a sanity test during installation. Honestly I'd rather remove the sanity test than have 1 in the installer script 2 seems fine, though I'd hope that if someone is messing with the SNMP config enough to bork the installation, they'd be able to just remove the sanity check from the PLG and call it a day. 3 would be hard to differentiate between a custom config and the default I think, or similar to 1 would be extra complication to the install logic. Out of these, 2 vibes the most with me!

NET-SNMP-EXTEND-MIB::nsExtendOutLine."disktemp".2 = STRING: WDC_WD100EMAZ-00WJTA0_JEGKPT5N: 30 Here's an example of how it will look. Here's one way of calling SNMP to get just the custom stuff: snmpwalk -v 2c -c public localhost nsExtendOutLine You can also uninstall and reinstall the plugin and the installation logs will give you an example of how to call SNMP, along with what your system's output currently is.

Huh, I didn't edit anything related to this bit. Specifically, what it's failing on is that it's trying to call snmpwalk after SNMP is started, and it's getting back "No Response from localhost" instead of a valid SNMP response. That sounds to me though as if SNMP failed to start up. - If you reboot and try to update again, does it work? - An alternative would be to uninstall SNMP, reboot, and then reinstall with the newest version. I'm not sure what version of SNMP/Unraid you're currently on, but there have been some adjustments in more recent versions to make updating safer.

Sorry it took so long! Thanks to @mattie112 I've just released update 2021.05.21 to main. If there are any bugs, it's probably due to my fiddling with the PR's code 😜 In essence, this update modifies the SNMP installer script to look on the /boot drive for an SNMP config file to use, preferring that over the bundled config if it exists. This means that even without using the UI, you can get a custom SNMP file to load up without any adjustments to the go file or anything else. The other, much more headache-causing section of the update is a new part of the SNMP settings page to customize the SNMP config, save it to the /boot drive AND overwrite the actively-used config, and then restart SNMP to apply the changes. A Default button is also provided to restore the SNMP config to the default file that ships with this plugin. Oh, I also tweaked the uninstall code to better clean up after itself. It seemed that the `rm` commands weren't working as expected with an asterisk, so I've updated it to properly clear everything out. As always, please enjoy and let me know if any issues arise. And again, thanks to @mattie112 for suggesting, implementing, and providing debugging help for this much-desired feature.

I'm looking at it now. Just merged it to the test branch and am testing a couple things out. Also going through your notes, they are super helpful! Glad to hear you're using the UI customization of snmpd.conf (and thank you again for contributing!), I'm sure others will have similar findings! Yes, this is by design! I am a big proponent of uninstallers removing all traces, rather than leaving the user to find what was left behind and what wasn't. Some other plugins do this as well: https://github.com/jbrodriguez/unbalance/blob/master/plugin/template.plg#L88 and https://github.com/dlandon/open.files/blob/master/open.files.plg#L163 for example. Meanwhile, and as you've noted, others remove only some of the files under the boot directory https://github.com/dmacias72/unRAID-NerdPack/blob/master/plugin/NerdPack.plg#L292 and https://github.com/StevenDTX/unRAID-open-vm-tools/blob/master/openVMTools_compiled.plg#L275 I'll keep it as-is for now but will definitely think more on it. Thanks for the call-out!

Looks great, thanks a ton! From an initial look through, I have a couple minor comments that I need to post (consolidate PHP into the .page file, lower/camel case variable naming) but the comment lines and general look and feel are fantastic. I realize there's no documented testing procedure, so I also want to give it a thorough run of different scenarios myself in terms of testing. Maybe I can even make a doc based on it 🤩 Fresh install, uninstall and reinstall, reboot, upgrade, *removal* of the custom config (does the default come back?), pre-population of the default config, a couple other things along those lines that will hopefully ensure it's resilient. I'm in the middle of another project so I hope to look at this within the next 3-4 days.

/boot/config/plugins/snmp/snmp.cfg is read from and written to by the SNMP settings page https://github.com/kubedzero/unraid-snmp/blob/main/source/usr/local/emhttp/plugins/snmp/snmp.page#L18 It then gets read any time the disk_temps.sh script gets run https://github.com/kubedzero/unraid-snmp/blob/main/source/usr/local/emhttp/plugins/snmp/disk_temps.sh#L72. /boot/config/plugins/snmp/snmp.cfg is not guaranteed to exist, so the disk_temps.sh script has to handle if the file is missing. ___ As for /usr/local/emhttp/plugins/snmp/snmpd.conf, it gets extracted to here from the .txz during Unraid SNMP package installation. Then during package installation, it copies over / overwrites /etc/snmp/snmpd.conf https://github.com/kubedzero/unraid-snmp/blob/main/source/install/doinst.sh#L38. This is done because it's easier to follow than doing hacky text replacement in /etc/rc.d/rc.snmpd to point at /usr/local/emhttp/plugins/snmp/snmpd.conf instead of /etc/snmp/snmpd.conf (the default). I also wanted to keep changes to /etc/rc.d/rc.snmpd to a minimum, since it's installed by the untouched Slackware snmp .txz and not *our* wrapper unraid-snmp > I see a form submit to '/update.php'. Is this an unraid file/feature Yes, I figured out its use by looking at other plugins with settings pages. Unfortunately there isn't much documentation for plugin creators. > Is there any way to quickly test things? Theoretically, if you wanted to make the SNMP config file configurable, you'd add a text field in the Settings page. Then from there you have a variety of choices, but no matter what you'd have to stop SNMP and then start it again with the correct parameters. I imagine that would be done by either triggering a shell script from the Settings page, or trying to do it all within the Settings page. You'd also have to do error handling for when the file being pointed to isn't present. You'd also have to handle boot scenarios since the unraid-snmp package reinstalls at boot time, meaning it would have to read the /boot/config/plugins/snmp/snmp.cfg if it exists, try to get the alternate location for etc/snmp/snmpd.conf, make the appropriate modifications, and then continue installation/starting of SNMP

That is the current version. Also, what version of Unraid are you running? The next thing I'd try is a reboot of Unraid to see if that helps. I have a suspicion that if you ran "head -15 /etc/rc.d/rc.snmpd" (which prints out the first 15 lines of the file, which is the part we care about) you might see a different start command than what it should be. Again, the old version of the plugin would modify this to point at the /usr/local/emhttp/plugins/snmp/snmpd.conf file by doing an in-place string replacement, but the new version does not. A reboot would fix this as the file is recreated at boot, which would be another reason for trying to fix this by rebooting start() { if [ -x /usr/sbin/snmpd -a -f /etc/snmp/snmpd.conf ]; then echo -n "Starting snmpd: " /usr/sbin/snmpd $OPTIONS -c /etc/snmp/snmpd.conf echo " /usr/sbin/snmpd $OPTIONS -c /etc/snmp/snmpd.conf" fi }

https://github.com/coppit/unraid-snmp/blob/master/snmp.plg#L197 The old version of the plugin (still linked in the first post of this topic) read from /usr/local/emhttp/plugins/snmp/snmpd.conf which sounds to be the issue you're facing. Are you using my latest version of the plugin, 2020.11.20, installed from Community Applications or https://github.com/kubedzero/unraid-snmp? It will start SNMP with the config file at /etc/snmp/snmpd.conf. Configuring the SNMP configuration via a GUI setting could be nice, please submit a PR!