s.Oliver

hey guys, i want to move makemkv activities also to the unraid box. now i have an old dvd/bluray combo-drive, but it reads blu-rays with only 1.6x (6.8 MB), so one disc takes around ~60 mins. does anybody have suggestions for an external usb-drive (can be a dvd-writer/bluray-reader, or even dvd-/bluray-writer combination)? would be perfect, if those are tested/known to work with makemkv-rdp container. would appreciate any ideas, thx.

well, well, i'll most probably rearrange my drives, so in the end the samsung will end up on a sata port of the MB. so it's then not connected any longer to the LSI and probably TRIM will then work.

Looking at your mb manual this is the problem, SAS3 is onboard LSI, when we say onboard controller we mean the PCH ports, connect the SSD to one of those and trim should work. just wanted to post back, that the SSD is connected to the LSI Logic SAS3008 chip – but you beat me well, i've choosen the faster SAS3 ports and usually passthrough of 3rd party controllers is easier than the MB-ports. well, i'll probably need to reconsider how to utilize all ports of the board. i've passthrough'ed another LSI Logic SAS2008 pci card to unRAID as well. but it seems then same game for these LSI controllers.

No, default BTRFS supports TRIM, you usually get that error when the controller doesn't support it, looks like you're virtualizing unRAID, so maybe that's the cause (if you're using the mb controller). you're right, i do virtualize unRAID, in that hardware controllers are passthrough completely to unRAID. all (to me) known/used hardware features (esp. such as sleep function of hdd) do work properly. even all operations, which do change the boot usb-stick – so no tricks used/necessary here. the SSD is on the same controller (SAS3 from MB) as other HDDs. not an TRIM expert here, but my reading showed, that they use the fstrim command on mountpoints of filesystems and not on devices directly. well, i tried that too, but same result.

>> bonienl is it maybe because the cache device is using (the defaulted) BTRFS? reading up a bit reveals, that BTRFS should support TRIM, but (might) dependent on used mount options. maybe the only quick solution is to format the SSD with EXT4? this page might shed some light on my issue: https://kb.plesk.com/en/122080 using the command on the mountpoint of the cache drive "/mnt/cache" shows the exact same output (also for the discard_max_bytes).

well, i know usually it is sent by sendmail. i thought, that unRAID uses it's own script or small proggy, which is sending out the email with regard to the settings in the "SMTP Settings". but, it seems we have two different use cases here: 1st for sending out only the specified in "Notification Settings" and 2nd for all system generated output. strange in use case two is, that unRAID is already using all defined parameters of "SMTP Settings", but only replaces the sender address with the "root@"-part. in my opinion it seems to be a small step from here to using the specified "from" sending address.

no, 6.1.9 as per signature. but why is the cron job then ignoring the settings for smtp? it is using root@ instead of the setup email-address.

First thing to check is if your SSD supports trim # hdparm -I /dev/sdX | grep TRIM (X = reference to your cache disk) root@unRAID:~# hdparm -I /dev/sdb | grep TRIM * Data Set Management TRIM supported (limit 8 blocks) Second question: is your disk directly connected to your motherboard or do you use an adapter? it is directly connected and does support trim (Samsung Evo 850). thx. for looking into it.

yes, gives this error: root@unRAID:~# /sbin/fstrim -v /mnt/cache fstrim: /mnt/cache: FITRIM ioctl failed: Operation not supported

first off, a great thank you to bonienl for these wonderful suite of plug-ins. a few days ago i installed the SSD TRIM plug-in (i somehow managed to ignore it for quite a while, beside running other Dynamix plug-ins ) and set it to fire at 8am every day. the very next day i checked the logs of unRAID to look for (maybe) any entries belonging to the plug-in. low and behold i found this one (removed private informations): Jun 23 08:00:02 unRAID sSMTP[20482]: Creating SSL connection to host Jun 23 08:00:02 unRAID sSMTP[20482]: SSL connection using XXXX Jun 23 08:00:02 unRAID sSMTP[20482]: Authorization failed (535 5.7.8 https://support.google.com/mail/answer/14257 u64sm2150802wmd.8 - gsmtp) ok, a bit confused (for a moment) – what has caused this? out of nowhere (and never before) something tried to send an email via google. the next second i remembered, ey i got the new plug-in installed – maybe it has any defaults to send reports automatically. checked the "Notification Settings" in unRAID, but they where like i had them set up: no eMail-Notifications, only in browser; no email-account informations in the "SMTP Settings" area. so i went ahead and configured the "SMTP Settings" with my account informations (with different sending/receiving addresses). i verified the setup by using the "Test"-button and immediately received the test-email – all well i thought. and the very next day log-check showed this: 08:00:01 unRAID sSMTP[x]: RCPT TO:<[email protected]> (553 5.7.1 <[email protected]>: Sender address rejected: not owned by user email-account) this error says that something (most probably the plug-in, because didn't happen before) tried to use the sender email-address "[email protected]" to send an email to the (correctly) specified "[email protected]"-address. but now, it correctly did try to use the google email-servers, instead it used the specified one. after re-checking all settings and test-sending emails from the "SMTP Settings" tab i came to the conclusion, that (maybe) the plug-in (or any used parts of unRAID for sending emails) has a hard coded sending email-address (root@) and ignores the specified one. now, you could ask, why then not use the [email protected]. because of security concerns. this email-server checks the sending email-address against the provided email-account; and if it can't verify that it is allowed, it denies it, hence the error in the log. wrap up: had no log entries up to now which are email related (and nothing configured for it) and just exactly one second after the (since then) newly installed SSD_TRIM plug-in fired, i'm pretty much confident, that it is caused by it. maybe some things play together here (functions of unRAID which are used for sending the actual email, or combinations of Dynamix plug-ins) but i think it can be fixed to work as expected. sorry for the long post, but it (hopefully) helps much better to track down this bug. greets, oliver

i'm myself a mac-user every since... well, long time ago. using macs natively means, you run on apple's HFS(+/journaled) file-systems. one of the features is, that files can have two forks (data/ressource). it was introduced (if i remember right) to allow the storage of additional metadata, while keeping full compatibility to the older version of HFS. but, most important, you never have to deal with them on apples side, because of the native file-system (os-implementation). not during creation, deletion, copying, or any kind of interaction (also because you don't see them). but, if those files get copied, created, moved, transferred from a mac-system (with active native apple file-system/or native software) on an different non-mac-native file-system, the destination file-system doesn't know anything about these metadata and simply creates those as separated files. i'm not even sure, if the mac uses these files while accessing them over the network on a file-server not using native apple file-systems. i'm not recalling any problem with a file, if the ._* part of it got deleted, or wasn't accessible/available while it got accessed. some backup-software even doesn't write those files to non-HFS file-systems, because they don't support them natively. anyway, it's on the other side a long, old story and apple didn't change a thing all over these years. they added newer features in newer versions of the protocol, but never dropped older ones or changed, how they behave on non-apple file-systems.

even better would be an integration into unRAID itself... because then it would not 1/ spin up all drives on a regular basis just to do a "expensive" lookup for these files (and deleting them as found) – thinking of my backup scenario with several 100 tsds of files... 2/ do this action for the sake of doing it, not knowing that sometimes no such files are newly created - and be a total waste of time/energy 3/ be implemented manually (and be forgotten then) and maybe once (with a update, change, etc.) get's broken or makes problems i would hope for an implementation by lime tech into unRAID itself. it maybe could be implemented like: whenever such mac-typically (hidden) files should be written to disk, unRAID (silently) accepts those file creations (but never writes them to disk). that would allow the mac programms to work as expected and filters out these files – even better: they never get written to disk, they never waste space, and they never need to be killed afterwards. the only exception i would think about is for the "TimeMachine"-share.

just to give back a little to the wonderful community - here a few mumblings... i'm using ProxMox 4.0 as native hypervisor on my machine and have unRAID 6.1.4 Pro running as guest. everything works (what i tested) perfect so far (*). anyway, to let you know beforehand: ProxMox doesn't passthrough virtualization features to guests (so i guess no virtualization inside a virtualized [unRAID] environment). dockers, of course, do work as expected. setup: kvm, 4 gb ram, passthrough'ed SAS3 controller and 1x usb-port boot-environment: Plopexec boots from usb-stick with installed unRAID (updateable, as like native) small hickups at first: SAS3-controller had not been with latest firmware at first. everything worked, but not the preclear plug-in. it showed a second line which should have been acknowledged with yes, but nothing happened. after updating the firmware to the latest one, even preclear worked fabulous. pre-clearing a 6 TB WD Red Pro took 34 hrs (Pre-Read 12,25 hrs + Zeroing 9,5 hrs + (Fast)Post-Read 12,25 hrs.). docker: plex (linuxserver.io) [works with Plex Pass] works pretty well so far, updates do get installed (restart docker once an update is available). i've taken over my big library (Mac based) and it worked immediately. network: performance is pretty good; i don't think there's a big loss of throughput 'cause of ProxMox. The cache SSD isn't used for copy-through-share, it's now just for dockers/data storage. reliability: after the installation (and setup specialities because of virtualizing of unRAID), i had not one problem! no crash, no slowdowns, all features work (spin down of disks, etc.). for example i copied alot of data over the network (quite a few days in one go) – i'm pretty happy here. my server gets alot of other VMs later on and needs to be independently from unRAID (no good to shutdown VMs cause of changes to the array, etc.). * [solved] unRAIDs dashboard believes eth0 isn't connected. and secondly a slowly, but steadily increasing number of reported dropped packets. both doesn't seems to lead to reduced networking speed, or connection problems/discovery. maybe it's related to ProxMox's network bridging setup. it was because i (automatically) used virtio also for the network - now switched that to an E1000 and no (not one) dropped packet. also the dashboard now sees the eth0.

thx. alot for all your work/time provided! ahh, just one more question: which (plex-server)-release steps are considered an update (with notification in the gui)?

ok, assumed, you pressed the power button not for too long! so i can be calm about it and believe, that a clear shutdown-sequence is initiated – but, because of super small system & resources used by the container it will be a very fast shutdown. so, for my other question on which linux distro and plex built you settled? thx.

hmm… interesting. i don't think that any kind of sanity checks are done from either the docker engine or unRAID itself, before they kill that running container. so probably we could just let sit the container a bit for itself (after any action that does update on disk contant – appdata, etc.), before giving the restart, stop, etc. command.

thx. Leifgg. another technical question to docker functionality: per web gui there isn't (or at least doesn't sound so) a safe way, too shutdown a container smoothly (or using it's OS provided shutdown procedure). how is it done internally, when i hit to button restart (for a container)? i don't want to get a damaged database, file structure, because i restarted that container and not, like i would do it on a physical box, using it's normal reboot function, which would bring down all programs smmothly, giving all processes time to save it's contents, etc.

hey, i'm new to plex on unRAID, so first up, thx. alot for peoples time to bring it to unRAID and supporting it. i appreciate that alot, 'cause i know how much work (time) is involved. just installed it and got it running, albeit not tested every feature. basically it has my library (before on Mac), all paths corrected to new unRAID location and a first test (using PHT on Mac) to check that it streams (locally). that works. now, i'm curious, how the update feature (Plex Pass member) should work, or better said, how i should expect it to work. alle settings are correct, it searches for PP-releases) and says it's up-to-date - currently 0.9.14.1. on plex.tv's website the latest is one increment higher (as of today 0.9.14.2.1547-60c867f; released 17th of nov.). my understanding was/is, that linuxserver.io implementation of the plex-server allows for direct updating, without any work on the maintainers site. is this correct? or does the maintainer-team need to update urls (or anything behind the scenes) to allow it to see it a new release? and (solely my personal interest) on which platform is this plex-server container based on (in comparison to plex.tv offered downloads)? is it one of the linux distros like ubuntu, or uses it the special unRAID built? greets, Blacky

Drive models seem to have unique sound signatures, as long as like drives all sound alike it's probably ok. What I don't like to hear is one drive making lots more noise than others of the exact same model. ya, these days it's called noise acoustic design. update: it took 12 hrs for stage 1 to complete. funny thing is, i started pre-clearing 4 drives nearly simultaneously (just with a few minutes difference), but the last in the row was the first to finish step 1 by quite a difference. same models, same onboard-controller, etc.

well, well... updated the firmware of the onboard sas-controller and now the pre-clear is running; 1st stage, pre-read 3% ~170 MB/s. one question to check correct operation: my drives do make some "crunching" sound; like when the read/write-heads are moving quite much, but always in the same relative movement so emitting the same rhythm/scrubbing-noise. is that normal? one would think, that it would be a linear, continuing (from begin to end) reading/movement.

hmm.... are there any better solutions out there? i would prefer the GUI vvariant of it, so i followed (and read) lots of articels about that combination plug-in & script. maybe i ask, what you do for pre-clearing?

thx. RobJ, but all other indications do tell something else. unRAID and the plug-in do read out all informations correctly. especially when i simply assign the drive to a slot, then unRAID does all smart-stuff correctly and does format/use the drive without problems.

hey gfjardim, hi guys! guess i got a problem here, somehow, somewhere... installed plug-in & latest script v1.15, everything looks good (file sizes, etc.). the PreClear page does show all unassigned drives. but when i start a preclear for a disk and accept all the default values (Clear, 1 Cycle, Read/Write size: Default, Skip Pr-read: NO) it says "Starting..." and never changing; even after a hour. this is for an 6 TB WD Red Pro drive, attached to the onboard SAS-controller. i can, however, format the drive without problem. on another new drive i observed quite a bunch of errors while formatting it, so this time i wanted to test all drives beforehand with preclear. when clicking the blue "observe/eye"-icon, i see this attached outputted – and please have a look at the last line: Pre-Clear unRAID Disk /dev/sdd ################################################################## 1.15 smartctl may not be able to run on /dev/sdd with the -d ata option. however this should not affect the clearing of a disk. smartctl exit status = 2 smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.1.7-unRAID] (local build) Copyright © 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org Read Device Identity failed: Invalid argument A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.$ Do you wish to continue? (Answer Yes to continue. Capital 'Y', lower case 'es'): Yes Disk /dev/sdd: 6001.2 GB, 6001175126016 bytes 255 heads, 63 sectors/track, 729601 cylinders, total 11721045168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes ######################################################################## invoked as /boot/config/plugins/preclear.disk/preclear_disk.sh -c 1 -W /dev/sdd ######################################################################## (MBR 4k-aligned set. Partition will start on sector 64 for disks <= 2.2TB and sector 1 for disks > 2.2TB) Are you absolutely sure you want to clear this drive? (Answer Yes to continue. Capital 'Y', lower case 'es'): it seems to need a last capital "Y" injected. any ideas, what's wrong with my installation? thx. Blacky

sorry for being late (maybe), but then, i'm not an unRAID user yet, but have ordered all necessary parts to built that new machine for unRAID and other purposes. DON'T KILL A FEATURE because of an hardware usage change, but rather CHANGE THIS FEATURE into something useful for todays usage patterns. as one user stated: change this feature to be useable on shares (default: disabled). this opens up a solution everybody can use, but has not to. probably most do use shares to access the data on drives, i'll definitely do so. and while it's beneficial to me as feature in this case, i don't try to figure out every-bodies else's usage scenario. and then, who get's hurt? it's optional. just my 2 cts here.