CS01-HS

The path directive supplies the path for a particular share. Not sure why I have to duplicate it in Extra since it's specified by unraid but it wouldn't work without it. These are share-specific directives so AFAIK it would only apply to the share whose path is /mnt/user (and creating that share might cause conflicts.)

I've improved the script including the use of smartctl to check USB drive status (which unlike hdparm works reliably with substandard USB interfaces my drive's substandard USB interface.)

Looks good.

It's in the beta. Switch your repository to emby/embyserver:beta or wait for the next release.

That's a way to get spotlight indexing working, I haven't tried it and haven't installed extra libraries. Have you tried stopping/starting the array? If you post your full smb extras maybe someone will spot a problem.

Are you sure there's not a typo in your config? I'm afraid I'm out of my depth here. I can say as far as I'm aware spotlight's not involved in SMB search - it should work immediately.

Put it in Settings -> SMB -> SMB Extras You have to stop the array to edit it. Here's what mine looks like with two shares: Private and Public, but I've customized it enough I forget what's changed from the default. I believe the highlighted lines are the only ones necessary to fix search.

Maybe it's backing up the full Recovery partition every time? Stab in the dark but I believe spotlight indexing of the mac and the backup plays a role. You can rebuild the mac index easily enough by turning it off: sudo mdutil -a -i off then on: sudo mdutil -a -i on but the backups are more complicated, maybe easier to start fresh. You can set multiple time machine destinations so you wouldn't have to wipe the old one.

That's what I'm getting at. We're blaming unRAID but I think Time Machine itself's the limiting factor. You can disable Time Machine throttling by running this on your Mac which might speed it up (it gets reset on reboot) sudo sysctl debug.lowpri_throttle_enabled=0 Still that log showing a 40GB backup in about an hour and a half isn't bad, better than what I get so it might be a combination of factors. Is there a good reason the backup was so large? Mine are usually around 1GB. Not sure about your "Recovery" error.

Has this fix stuck? Approximately how long does it take to complete a backup and of what size? Mine is about 20 minutes for 700MB but I wiped and re-started my backup set a few days ago so it might slow down over time. You can run this command in an OS X terminal to see details as time machine runs: log stream --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --debug I think it would help if we had a baseline - what's the fastest we can expect with networked backups whether that's to unRAID, synology, Time Capsule, a shared Mac, etc. So far my unRAID pool beats Time Capsule.

Click the link once and it'll open a pop-up window with a login prompt. Click it again and the pop-up will display what it should have the first time. That's a workaround. I don't think there's a fix.

UPDATE: I applied the fix described in @limetech's linked comment - problem solved.

Are you running embyserver:beta ? I got the same error but only with the latest beta (4.6.0.34) You can wait for a fix or specify the previous beta in Repository: emby/embyserver:4.6.0.33

Right. In my example the file only existed on Share A prior to the move. I ran a test: Uploaded test.mp4 to share Public Moved test.mp4 from share Public to share system Result: test.mp4 exists in share system and in share Public's recycle bin Note: This is over SMB from a Mac client Both shares have cache enabled test.mp4 existed on neither share prior to the test Here's the File Activity log beginning just before the move (note the last few lines) EDIT: I suspect there's no specific SMB command to "move" files between shares and what's happening is the client first copies (to the destination) then deletes (from the source) so there's no way for your plugin or any other to differentiate. I tried to confirm but this low-level samba stuff is beyond me. Long-winded way of saying "you should probably ignore my original post but users beware of large moves." ** Cache Mar 21 12:00:29 OPEN => /mnt/cache/Public/.DS_Store Mar 21 12:00:29 ATTRIB => /mnt/cache/Public/.DS_Store Mar 21 12:00:29 ATTRIB => /mnt/cache/Public/.DS_Store Mar 21 12:00:29 CREATE => /mnt/cache/system/test.mp4 Mar 21 12:00:29 OPEN => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:29 OPEN => /mnt/cache/system/test.mp4 Mar 21 12:00:29 OPEN => /mnt/cache/system/test.mp4 Mar 21 12:00:29 OPEN => /mnt/cache/system/test.mp4 Mar 21 12:00:30 OPEN => /mnt/cache/Public/test.mp4 Mar 21 12:00:30 OPEN => /mnt/cache/system/test.mp4 Mar 21 12:00:30 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:30 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:30 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:30 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:30 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/Public/test.mp4 Mar 21 12:00:31 OPEN => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/system/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/Public/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/Public/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/Public/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/Public/test.mp4 Mar 21 12:00:31 ATTRIB,ISDIR => /mnt/cache/Public Mar 21 12:00:31 ATTRIB,ISDIR => /mnt/cache/Public/ Mar 21 12:00:31 CREATE,ISDIR => /mnt/cache/Public/.Recycle.Bin Mar 21 12:00:31 ATTRIB,ISDIR => /mnt/cache/Public/.Recycle.Bin Mar 21 12:00:31 ATTRIB,ISDIR => /mnt/cache/Public Mar 21 12:00:31 ATTRIB,ISDIR => /mnt/cache/Public/ Mar 21 12:00:31 MOVED_FROM => /mnt/cache/Public/test.mp4 Mar 21 12:00:31 ATTRIB => /mnt/cache/Public/.Recycle.Bin/test.mp4 Mar 21 12:00:32 OPEN => /mnt/cache/system/test.mp4 Mar 21 12:00:32 OPEN => /mnt/cache/system/test.mp4

If I move a file (over SMB) from Share A to Share B, and Share A has Recycle Bin enabled, the file will exist on Share B and in Share A's Recycle Bin. Essentially duplicated. Not the biggest problem but if say someone did a bunch of moves between cache-enabled shares it could end up unexpectedly filling the cache pool. Has anyone else noticed this? I'm on a Mac client and I've tweaked some SMB parameters so it's possible this is a "me" problem.

I noticed none of the containers I have routed through this one could communicate with services on LAN IPs. I found the solution in A27 of the FAQ: Adding a variable VPN_OUTPUT_PORTS with a list of port exceptions (mine are Emby and SMTP) I didn't see this mentioned here (maybe it's new) so I thought I'd mention it.

Is there a risk of data corruption if unraid spins down the disk while another partition is being written to? That'd be my only concern.

Actually the latest versions of UD relinquished spin control to unRAID so disks in UD spindown according to the default unRAID spindown timer. Maybe you just have to wait longer or maybe you're encountering the same problem I did - where the USB drive returns an error when spindown's called so even though it's spun down unRAID thinks it's active. I have a fix but I'm not confident enough in it to really recommend it:

Yup, both zeros. Now I see what you meant. I had to wait for the temperature to disappear again before I cat'd devs.ini but it did and they match up: ["dev2"] name="dev2" id="ST4000VN008-2DR166_ZGY68" device="sdc" sectors="7814037168" sector_size="512" rotational="1" spundown="1" temp="*" numReads="0" numWrites="0

Maybe I'm misunderstanding or I wasn't clear but the relevant disk is Dev 2 (sdc) which shows ~150MB/s reads in the screenshot. I'm not planning to run hdparm -y but I took the last line of that log: spinning down /dev/sdc to mean that unraid had.

Ah, I bet that's because the fix for spindown in 6.9.1 was to monitor partition stats rather than disk stats and pre-clear writes/reads directly from the disks. I wonder if there's a risk running hdparm -y during the write phase - I guess I'll find out soon.

I know unRAID handles UD spindown so I wasn't sure where to post this but I'm pre-clearing a disk and unRAID and/or UD seem confused about its status. Temperature will sometimes display and sometimes not (as if the disk were in standby) and unRAID keeps trying to spin it down. Strange. No problems as far as I can tell, just a heads up.

I don't want to derail further but for anyone following, I ended up customizing sdspin to ignore "bad/missing sense" returns from USB drives, so I can uninstall the plugin (I have no SAS drives.) Thanks for the plugin and your help - otherwise I never would have found the fix.

Okay I figured out what's causing this. I have this block in my SMB Extras: #unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end And on boot the file it references is populated: root@NAS:~# more /tmp/unassigned.devices/smb-settings.conf include = /etc/samba/unassigned-shares/usb-hdd.conf root@NAS:~# more /etc/samba/unassigned-shares/usb-hdd.conf [usb-hdd] path = /mnt/disks/usb-hdd browseable = yes force User = nobody ... Which explains why it's shared. If I share then un-share the partition in the WebGUI it blanks the file and all's well. root@NAS:~# more /tmp/unassigned.devices/smb-settings.conf ******** /tmp/unassigned.devices/smb-settings.conf: Not a text file ******** root@NAS:~#