CS01-HS

Members
  • Content Count

    240
  • Joined

  • Last visited

Everything posted by CS01-HS

  1. As long as you're happy with 6.8.3. 6.9.0 dropped AFP support.
  2. Wow that's comprehensive. It's unfortunate Apple chose to deprecate it. I was surprised to see in your tests with small files that Windows wasn't much better than Mac. I assumed Mac was the biggest culprit but this suggests it's SMB itself or unraid's implementation. I guess to narrow that down you could benchmark a non-unRAID SMB share.
  3. I haven't tested enough to gauge the relative effectiveness of each of these tweaks (some may even be inadvisable) but overall my Time Machine backups are working "reasonably" in 6.9.0-RC2 In Samba extra configuration: [global] #Fix for 6.9.0-rc2 Mac client search spotlight backend = tracker # speed tweak nt acl support = No # tweaks from https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X min protocol = SMB2 fruit:metadata = stream fruit:model = MacSamba fruit:posix_rename = yes fruit:veto_appledouble = no fruit:wipe_
  4. I assumed Apple was phasing out old model types, in which case it'd make sense for unraid to use a more recent one. But right, maybe they just forgot and plan to fix it.
  5. Extract a Single File(s) From a Large Tarball
  6. I set it up as a user script to run hourly but honestly can't remember why. It would make sense to put those lines in config/go so it's run on startup, but maybe that doesn't work because smb.service is overwritten on array start? The fix for that would be to set the user script to run on array start but I didn't do that either, strange.
  7. I'm having the same problem with "missing csrf_token." I tried a server restart to fix it, didn't help.
  8. Update: As of Emby 4.6.* (currently in beta) which includes an iHD driver with fixes for Gemini Lake it's no longer necessary to disable iHD.
  9. I assumed this slowness was specific to my Mac environment - painfully slow Time Machine backups. Looks like it's unRAID, huh.
  10. I've done some digging on this - here's what I found. Mount unraid share system on my mac and check its spotlight status: [macbook-pro]:~ $ mdutil -s /Volumes/system /System/Volumes/Data/Volumes/system: Server search enabled. [macbook-pro]:~ $ But as best I can tell "server search" is not in fact enabled. Turns out samba 4.12.0 changed this search-related default: Note that when upgrading existing installations that are using the previous default Spotlight backend Gnome Tracker must explicitly set "spotlight backend = tracker" as the new default is "noindex
  11. This is worse than I thought. I created a directory in the unraid console owned by root and not readable, writable or executable by anyone else: mkdir /mnt/user/Download/TV/y chmod go-wxr /mnt/user/Download/TV/y drwx------ 1 root root 20 Jan 11 18:49 y/ And apparently any user in my sonarr container (not set as privileged) can write to and delete from it freely. This can't be intended behavior, can it?
  12. Thanks. A slight variation on your suggestion, I re-ran the test but with x as directory (rather than file) - same problem: docker exec -u 99 -it EmbyServer sh / $ mkdir /media/TV/x / $ chmod go-wx /media/TV/x / $ ls -l /media/TV/ | grep 'x' drwxr--r-- 1 99 root 0 Jan 11 12:09 x So directory x should only be writable by nobody Let's see if that's true: docker exec -u 1006 -it sonarr sh $ whoami abc $ grep abc /etc/passwd abc:x:1006:100::/config:/bin/false $ ls -l /tv/ | grep x drwxr--r-- 1 99 root 0 Jan 11 07:09 x $ echo 'dodeedododeedo' &
  13. I created an unRAID user limited (id 1006) which I'm trying to use to limit write permission in docker containers that support PUID. Can anyone explain the following behavior? Launch EmbyServer shell with user nobody # docker exec -u 99 -it EmbyServer sh Create a file writable only by nobody / $ touch /media/TV/x / $ chmod go-w /media/TV/x / $ ls -l /media/TV/x -rw-r--r-- 1 99 root 0 Jan 11 11:35 /media/TV/x Launch sonarr shell with user limited # docker exec -u 1006 -it sonarr sh Confirm I'm limited (id 1006): $ whoa
  14. Changed Status to Closed Closing this because I don't think it's unRAID-specific. Maybe it's the new kernel or new driver but I had a bunch of video-related problems (including system freezes) until I added intel_iommu=on,igfx_off to syslinux config and installed a dummy HDMI plug. It's been stable since.
  15. After several freezes (which caused unclean shutdowns) in Handbrake using the hardware encoder and also with monitoring, and random corrupted encodes, I got my machine stable with the following changes: Added intel_iommu=on,igfx_off to syslinux config (this may be optional) Added a dummy HDMI plug to my headless server (j5005) It's been stable now for several days despite continuous hardware encoding in Handbrake with no corruption.
  16. Are you sure it won't work with the built-in "UPS Settings" ? Support seems to vary model-to-model and mine's a low-end unit. Otherwise I can't help much with customization of the NUT plugin. The reason I connected it to the Pi was to allow me to tweak it. Maybe post to that thread?
  17. Apparently there are advantages to 10 bit encoding even of 8 bit videos with minimal impact on file size, so no great loss. I have another question re: hardware acceleration: I notice with certain videos, decode consumes all my CPU with GPU (for encode) sitting at 2-3%. I see some references on the web to an option Enable QuickSync Decoding but I don't see it in the docker. Am I missing it, has it been removed, are there good reasons not to run it regardless? Thanks by the way, even hardware encode has reduced encode time by a factor of 10 in some cases. Amazing im
  18. Thanks. That led me to this https://github.com/chris1111/VoodooHDA-OC which finally got audio working on my j5005. I thought I'd have to stick with clover (where it worked by default.)
  19. It's a reporting tool. If you're not running the telegraf docker or a docker that incorporates it (like "GUS") then you probably don't have it. So you'll need to identify what's making the calls, guess and check or the wrappers. Easiest to wait for RC3 I think. The extra hours on your drives will be a negligible percent of total lifetime.
  20. That's consistent with what I'm seeing - the calls don't wake drives just prevent spindown. Try disabling telegraf and autofan if you haven't already. That's the only fix at the moment.
  21. Thanks for incorporating the latest Intel driver with h265 fixes for Gemini Lake, I've been waiting to test it out. I'm having a strange problem though - on my j5005 qsv_h265_10bit hardware encode works perfectly, but qsv_h265 (8 bit) hardware encode fails with the following error: [04:52:23] qsv_hevc_make_header: MFXVideoCORE_SyncOperation failed (-17) Any guess whether that's a problem with the driver or with handbrake?
  22. If that doesn't solve it (and you're comfortable enough not to break things) you can try these wrappers to smartctl and hdparm to identify what's calling them. Again this only applies to the RCs, if you're running 6.8.3 o betas I don't think it was an issue.
  23. If you're on RC2 smartctl calls from telegraf (and I believe Auto Fan) will prevent spindown.