kubed_zero

Members
  • Posts

    124
  • Joined

  • Last visited

Everything posted by kubed_zero

  1. Right on. The install script does a sanity check to ensure it's working correctly, and fiddling with the snmpd.conf file can absolutely get it in a state where the install script no longer works. I can't think of a good way of validating the install was successful while also allowing for custom snmpd.conf files. For those adventurous enough to modify the config, I'm hoping they're also confident in editing the PLG to disable the sanity test and allow installs to proceed. And also as you noted, if one gets into a bad state, deleting the SNMP files from /boot and rebooting would be a surefire way of starting from scratch. The logs posted by @dgaglioni showing "unraid-snmp-2021.05.21-x86_64-1 (already installed)" indicates that this was not a fresh install.
  2. Got it. Well, if there's anything I can help with (different settings, additional logs on the macOS or Unraid side, reverting to 6.9.2 and diffing outputs, etc) let me know!
  3. Still no luck on getting Time Machine to work with Unraid 6.11.1. Nothing shows up in the syslog to indicate a crash of SMB. The typical "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading}" still shows up on the MacOS (12.6) side. I've got zero extra Samba custom configurations/files, so this is running with vanilla Unraid as far as I'm aware. testparm -sv shows the following: https://pastebin.com/mmYPTz9n Specifically, here is the share for TimeMachine [TimeMachine] path = /mnt/user/TimeMachine valid users = backup vfs objects = catia fruit streams_xattr write list = backup fruit:time machine max size = 1200000M fruit:time machine = yes fruit:encoding = native @limetech As requested, I've output diagnostics from Unraid as well immediately after a reboot and failing to back up from two different computers. pbox-diagnostics-20221017-1212.zip
  4. Great to see. Hopefully this will help correct the Time Machine incompatibilities many people are seeing after 6.10. More details in and
  5. If you use SNMP without adjusting any of the default settings, it should work without a hitch. Those that have had issues still have not been able to tell me as the maintainer what exactly to do to reproduce their issues, so as far as I know there shouldn't be any problems with running this plugin. At the end of the day, this plugin is just a wrapper script to install the SNMP Slackware package, so in the worst case you could just default to installing SNMP manually.
  6. My guess, in conjunction with your Docker logs, is that somehow the localhost address isn't configured/accessible. There's some discussion earlier on in the thread, though I don't think we ever collectively got reproduction steps to isolate whether or not this was the case. The thinking with this SNMP install script is that localhost should be available since Unraid would just be pinging itself, and then that /boot exists on all Unraid installations and should be good to baseline. If either one of those fails to be true, then the installation script fails. That said, SNMP might have actually been installed, and perhaps these tests aren't passing for some reason. I suspect that Docker networking might be fiddling with localhost, but don't use Docker myself so I've been unable to reproduce. I'd say you have two options here: - Try to figure out if localhost is working, or if SNMP is working at all. Mess with Docker networking, install SNMP manually, and just generally deep-dive on your system - Remove the validation lines from your local copy of the PLG file, which on next install would just skip over the validation and treat it as a successful install. You could strip it all out, or just remove the "exit 1" line https://github.com/kubedzero/unraid-snmp/blob/main/snmp.plg#L195
  7. Yes! I think this is all you need.
  8. Another option is just to downgrade to 6.9.2. Time Machine has been working flawlessly on all my machines for the past few weeks since performing the downgrade!
  9. @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
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. 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.
  15. 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.
  16. 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.
  17. 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!
  18. 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.
  19. 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.
  20. 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.
  21. 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!
  22. 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.
  23. 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.