CS01-HS

Anyone else getting very high latency and low speeds with PIA's wireguard? Here's a speedtest from within an unRAID VM: $ curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python - Retrieving speedtest.net configuration... Testing from Optimum Online (XX.XX.XXX.XX)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Syndeo Solutions (Springfield, MO) [1748.93 km]: 48.05 ms Testing download speed................................................................................ Download: 103.52 Mbit/s Testing upload speed................................................................................................ Upload: 33.52 Mbit/s And here it is on the same machine from within the container (configured like so): # grep Endpoint /mnt/cache/appdata/binhex-qbittorrentvpn/wireguard/wg0.conf Endpoint = bahamas.privacy.network:1337 # docker exec -it binhex-qbittorrentvpn sh sh-5.1# curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python - Retrieving speedtest.net configuration... Testing from Redcom-Internet (XX.XXX.XXX.XX)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Gold Data (Miami, FL) [295.19 km]: 1927.194 ms Testing download speed................................................................................ Download: 8.65 Mbit/s Testing upload speed...................................................................................................... Upload: 7.85 Mbit/s I tried adding the following to Extra Parameters per the guide but it doesn't seem to make a difference. --sysctl="net.ipv4.conf.all.src_valid_mark=1"

Anyone using this for iPhone sync to a Mac VM? (Apple imposes a bunch of extra requirements.) My current setup is precarious so I'm reluctant to tweak it.

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

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.

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.

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:~#

Okay, mystery solved. Compare the return code from your version to unRAID's: root@NAS:~# sdspin /dev/sdb down; echo $? SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 80 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 root@NAS:~# cp /usr/local/sbin/sdspin.unraid /usr/local/sbin/sdspin root@NAS:~# sdspin /dev/sdb down; echo $? 1 root@NAS:~# Now the two scripts: Unraid's returns 1 (RET=1) hdparm () { OUTPUT=$(/usr/sbin/hdparm $1 $RDEVNAME 2>&1) RET=$? [[ $RET == 0 && ${OUTPUT,,} =~ "bad/missing sense" ]] && RET=1 } ... exit $RET Yours executes this block else # Not SAS $DEBUG && echo $HDPARM -y $RDEVNAME $HDPARM -y $RDEVNAME > /dev/null fi without catching a return code then hits the last line, returning 0 exit 0 # Just in case :-)

sdspin! That's what I was looking for, thank you. I mistakenly assumed that script was specific to your plugin. And I see the plugin helpfully saves the default version so I'll dig in and figure out the difference.

Good eye re: hdparm printout, I missed that. Okay but I'm pretty sure unRAID doesn't call hdparm directly - it issues some other command (smartctl?) that then calls hdparm. That call (and its parameters for UDs) is what I'm after - if you happen to know. Re: USB spindown, I can bore you with details if you want?

Plugin was installed but debug was disabled. I re-enabled it (with touch /tmp/spindownsas-debug) and tested again - same results, no additional printouts: root@NAS:~# touch /tmp/spindownsas-debug root@NAS:~# sdspin /dev/sdb down /usr/sbin/hdparm -y /dev/sdb SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 80 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@NAS:~# echo $? 0 root@NAS:~# sdspin /dev/sdb root@NAS:~# echo $? 0 root@NAS:~# It's a USB drive so I can tell by feel when it's spun down and it is. Spin down worked even without this plugin, problem was unRAID wouldn't detect it. My guess is this wrapper suppresses the error code from "bad/missing sense data" which is fortunate for me but it probably shouldn't. I still don't know the exact command unRAID calls to spin down Unassigned Devices. Do you? I assume it's smartctl but with what parameters exactly? (This is getting outside the scope of your plugin.)

Done. Same results whether the drive is active or already spun down. root@NAS:~# sdspin /dev/sdb down SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 80 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@NAS:~# echo $? 0 root@NAS:~# sdspin /dev/sdb root@NAS:~# echo $? 0

v6.9.1 I changed DEBUG to true in /usr/local/emhttp/plugins/sas-spindown/functions and ran: touch /tmp/spindownsas-debug

Interesting: I don't have SAS drives but I do have a USB drive (Unassigned Device) with a faulty interface that prevents unRAID from properly detecting idle status - so (a) the webGUI shows it spunup regardless of status and (b) unraid issues it a spindown command every spindown interval. Faulty interface (sdb is the USB): root@NAS:~# hdparm -C /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 80 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: unknown I installed this plugin thinking I'd use the code to write my own wrapper but mysteriously it's solved my problem - the drive's status in the webGUI is accurate and no unnecessary spindown commands. Thanks? Debug log in case you're curious:

Nothing obvious but maybe because I did the fix. I'll wait 'till it happens again and compare. Thanks.

Attached. Thanks. It's really minor so no need to fix my case, I only posted in case it indicated a general problem that affected more users. (If it's relevant, I think it popped up some time in the last couple/few months.) nas-diagnostics-20210314-1537.zip