• Content Count

  • Joined

  • Last visited

Everything posted by CS01-HS

  1. Assuming that's an array share and not an unassigned device, go to Shares then click the share and you'll see the field Enable Copy-on-write. Disabling it when creating a new share works (which means you'd have to start over) but I don't think changing it for an existing share with existing directories will, although there may be a way to manually convert it. In my experience though these are all marginal tweaks, I'm not sure there is a way to get fast time machine backups. I switched from a Time Capsule to unRAID hoping to speed things up. If it has it's not by much.
  2. Great. If you have the UPS set to shut itself off after issuing shutdowns make sure that delay is set long enough that the servers have time to shutdown. I mention it because out of caution I suggested stopping the array which consumes most unraid's shutdown time.
  3. This doesn't confirm your "shut down after" setting works but you can confirm the shutdown procedure works by STOPPING THE ARRAY (to avoid data corruption if something goes wrong) and running upsmon -c fsd From help: usage: upsmon [OPTIONS] -c <cmd> send command to running process commands: - fsd: shutdown all master UPSes (use with caution) - reload: reread configuration - stop: stop monitoring and exit -D raise debugging level -h display this help -K checks POWERDOWNFLAG, sets exit code to 0 if set -p always run privileged (disable privileged parent) -u <user
  4. A few observations from my testing. SMB random read/write performance in MacOS stinks. I'm using Big Sur and it's still worse than the old AFP method. Still you're getting relatively terrible performance. My initial ~150GB backup over wireless took about half a day. One of the recommended SMB tweaks is disabling signing. Have you done that? It may require a reboot to take effect: $ more /etc/nsmb.conf [default] signing_required=no I think? the spaceinvader tutorial sets an unassigned device as the time machine share. That's good because it bypasses the cac
  5. I upgraded to beta35 then installed intel-gpu-telegraf for the first time. I'll try again and report back
  6. Here's a strange problem: I have an always-attached (mechanical) USB hard drive mounted through UD. I have SSD Trim set to run 7AM daily through the built-in scheduler. It seems? unRAID recognizes this USB disk as an SSD and tries to trim it. I don't know if that's because UD's reporting it as an SSD or SSD detection happens outside UD. (I don't see the error every time trim runs but syslog server's been buggy lately so maybe it's just not logged.) Sep 30 07:00:03 NAS kernel: blk_update_request: critical target error, dev sdb, sector 76096 op 0x3:(DIS
  7. Since 6.8.3 I've used a modprobe call in config/go to load the i915 drivers. In beta35 this still works (with or without a monitor connected.) The new method however (touch /boot/config/modprobe.d/...) only works with a monitor connected. Without a monitor it doesn't boot to a point where I can ssh and investigate. nas-diagnostics-20201202-1340.zip
  8. I updated, tested and confirmed it now passes that parameter but only if Force all SMB remote shares to SMB v1 = Yes. It doesn't pass it if it degrades to SMB1 after failing higher versions. Not a problem if that's by design. Nov 23 17:59:31 NAS unassigned.devices: Mount SMB share '//' using SMB1 protocol. Nov 23 17:59:31 NAS unassigned.devices: Mount SMB command: /sbin/mount -t cifs -o rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=1.0,credentials='/tmp/unassigned.devices/credentials_Data' '//' '/mnt/disks/time-capsule'
  9. Ha! I saw that and thought "how could I miss that in the logs?" but I get continuous "bogus file nlink value" cifs errors with SMB1 so by habit I end every syslog tail with | grep -vi 'cifs' which of course removes it. I'm glad my stupidity wasn't an obstacle. Thanks again.
  10. Nice, thank you so much. Do you mind telling me how my diagnostics helped? Maybe a hidden UD log that might help me in the future.
  11. Sure, thanks. There's a bunch of spam in my syslog from an incompatible docker, let me know if you want me to clean it up. nas-diagnostics-20201123-1144.zip
  12. I may be an edge case but in beta35 this (very handy) docker fills up my syslog with the following error until the system's overloaded. Nov 23 10:00:10 NAS kernel: bad: scheduling from the idle thread! Nov 23 10:00:10 NAS kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.18-Unraid #1 Nov 23 10:00:10 NAS kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J5005-ITX, BIOS P1.40 08/06/2018 Nov 23 10:00:10 NAS kernel: Call Trace: Nov 23 10:00:10 NAS kernel: dump_stack+0x6b/0x83 Nov 23 10:00:10 NAS kernel: dequeue_task_idle+0x21/0x2a Nov 23 10:00:10 NAS kernel: __schedule+0
  13. The latest version won't mount my SMB1 share. I think it might not be passing sec=ntlm but I don't see a mount command in the logs. Any way to debug it? I've tried removing/readding the share with Force all SMB remote shares to SMB v1 set to Yes (as I had it) and No, neither works.
  14. I've updated the instructions to include temperature display.
  15. It happens on multiple computers, from Mojave to Catalina to Big Sur. It worked on all of them with 6.8.3. It broke sometime after I installed the first beta (beta25.) I'm pretty certain that's the culprit - the question is whether it's a bug in the release or something went wrong during the install process, maybe particular to my setup. To answer that it'd be helpful to know whether it's working with the beta for anyone on MacOS.
  16. Reasonable assumption but with same MacOSs searches on my Raspberry Pi share (with the standard packages) work properly. *Website is the Raspberry Pi share.
  17. In case it's not clear from my description here it is in pictures: A search of "debian" in my isos share (which clearly contains it) returns no results. Searching the full name debian-10.3.0-amd64-netinst.iso also returns no results. This problem persisted through the upgrade from beta30 to beta35, and from Catalina to Big Sur.
  18. I'm also curious. This line in the release notes, best I can tell, does not suggest i915 wasn't included in previous releases, only that it's among those now included - otherwise the modprobe command wouldn't have worked in previous releases, right? If so there's a new way to load it but the earlier way also works. I confirmed by upgrading, rebooting (without changing the go file) and testing the Emby docker.
  19. Maybe an oversight by Apple or maybe intentional. NAS is my unraid server. The closest supported server type I found was macpro-2019-rackmount so I customize the smb.service with the following script: cp -u /etc/avahi/services/smb.service /etc/avahi/services/smb.service.disabled cp /boot/extras/avahi/smb.service /etc/avahi/services/ chmod 644 /etc/avahi/services/smb.service touch /etc/avahi/services/smb.service.disabled Where /boot/extras/avahi/smb.service looks like: <?xml version='1.0' standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group S
  20. No. Just a simple search in the Finder window of a share.
  21. Still a problem in beta-35. Am I the only who searches SMB shares or are others not experiencing this?
  22. After enabling some disk-related power saving features I occasionally see the error below in the logs. Is it anything to worry about? ata3 is a mechanical disk connected to my motherboard's ASM1062 controller. I don't see any indication of a problem except the log message. Nov 13 04:05:04 NAS kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Nov 13 04:05:04 NAS kernel: ata3.00: supports DRM functions and may not be fully accessible Nov 13 04:05:04 NAS kernel: ata3.00: supports DRM functions and may not be fully accessible Nov 13 04:05:04 NAS kernel: ata3.
  23. I do. Diagnostics and saved syslog attached. Parity check starts: 06-11-2020 07:35 finishes: 06-11-2020 21:01 You'll notice a lot of BTRFS messages. What caused the dirty shutdown was a system freeze while running rebalance. syslog- nas-diagnostics-20201107-1753.zip
  24. I thought the error might have been legitimate until I rebooted and it went away. Are the post-reboot diagnostics useful? If they are let me know and I'll upload them. EDIT: Looks like I changed the bug status. Sorry about that, not sure what I changed it from.