kubed_zero

Members
  • Posts

    121
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

kubed_zero's Achievements

Apprentice

Apprentice (3/14)

13

Reputation

  1. Great to see. Hopefully this will help correct the Time Machine incompatibilities many people are seeing after 6.10. More details in and
  2. 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.
  3. 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
  4. Yes! I think this is all you need.
  5. 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!
  6. @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
  7. 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.
  8. 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.
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 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.