Xaero

See this thread: If you have any dockers with manually assigned IP addresses, try disabling those dockers and see if the issue persists. The line starting with R I P : is your hint. nf_nat_setup_info belongs to netfilter, so the party responsible for causing this crash is also netfilter. I think this is used by docker to assign the ip addresses internally - which would explain this behavior both in the linked post, and in your case. It's not up to limetech to fix this - but they should be aware of this issue. Also see this defect report:

You could also use the UMASK variable to do what I suggest in the other thread; the first bit (normally untouched) is the SET mode for the file - this can be 0 (normal file or directory), sticky, GID, UID, etc. control. By setting, for example 2000 it would change the first bit to "2" and then the "000" mask would translate to "666" or RW for Owner, RW for Group, and RW for anyone else. https://wintelguy.com/umask-calc.pl Here's a good calculator that will calculate permissions for you as well. I'm not sure what permissions its setting wrong - but the normal unraid permission of "0000" should work fine for SMB users to Read and Write. The SetGID bit can be useful when you wish to specify access to users in the group rather than the owner directly. Another useful setting for the UMASK: 0003 - this would make it so that the Owner (nobody) and users in the group (users) could read and write the file - but others (anonymous SMB users, for example) would be able to view the content, but not edit or remove it. EDIT: If you wish you can run "stat filename" on a file that is broken, and then run it on a file that is working to identify what permissions differ, which will better help identify what needs to be corrected. EDIT2: I see you already posted permissions set on two files above; Owner Group | Other Owner(UID) Group (GID) d rwx | r-x | r-x 1 nobody users d rwx | rwx | rwx 1 nobody users As you can see above - only the owner is set to have write permissions on the file created by the new installation that is "broken" Note that the execute bit (x) is required for directories to be browsable on Linux - the "d" to the left designates this is a directory, for files this is a "-" Changing the UMASK to 0000 should fix your problem, as it will enable write permissions for the group and other columns. For information on "why" this would be different; UMASK 0022 (no change to SET bit, owner read/write, group read only, other read only) is the typical default on Linux, and would result in directories being created with the permissions you are seeing above (remember - directories must have the execute bit, and it is automatically added when the directory is created.)

Correct, the PUID and PGID are the UID and GID of the username and group that file ownership is determined with. You can list all the groups, with their ID's using the groups file and a little bit of awkfu to list only the group names and gids: awk -F: '{ print $1,$3 }' /etc/group You can do the same for users: awk -F: '{printf "%s:%s\n",$1,$3}' /etc/passwd *snip* posted relevant info into your other thread. Please avoid crossposting as now we are splitting information into two places instead of one.

Look at your full smart report for the cache disk and see how much of your surplus flash is available. If the disk has had to mark areas of the flash invalid, and is no longer able to cycle written bytes into the garbage collect queue, then any new writes will require a zero-write prior to filling with data. This will cause the system to wait for the SSD to discard that area of the nand. This issue becomes much more apparent with lower free space as the SSD must then shuffle data around to create a contiguous section to accept the new block of data. I see you work in the storage industry - so I'd be surprised if you hadn't looked at this already - but its worth mentioning anyways.

You may try using setgid to make the owner the group of the directory. You should chmod g+s /path/to/directory Newly created files in the directory will inherit the setgid bit. note: SetGID being used for this purpose will also require that the group have read and write permission on the directory. Files created will then also inherit this from the directory with SetGID. I'm not sure how docker interacts with this - it may defeat setgid due to the nature of containerization.

If you compile the binary with static links it will be portable as any and all libraries will be compiled into the binary itself. This will result in a substantially larger footprint for the executable both on disk and in memory - but will get the job done.

Here's a bit of comical history; The "4-pin Molex" we all commonly refer to for IDE power connections is actually an AMP product (now owned by TE-Connectivity) from the "Mate-N-Lock" line (1-480424-0): https://www.mouser.com/ProductDetail/TE-Connectivity-AMP/1-480424-0 We refer to at as Molex as the legacy 4-pin connector which had a V shape to one side, is a Molex product. The below part appears to be the "punch down" style 4-pin connector in the "Mate-N-Lock" series https://www.mouser.com/datasheet/2/418/NG_CD_794036_C-1259633.pdf This document has more information on that connector and it's associated parts: https://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=82181_SOFTSHELL_STANDARD_DENSITY&DocType=Catalog+Section&DocLang=English&PartCntxt=794036-1 You are looking for both the Insulation Displacement Connector (IDC) and the Dust Cover for that same connector. They have them available in various colors. Note that the 794036 may not be the connector we actually want here - but this should point you in the correct direction. Page 29 I think is the correct page.

I believe that behavior is normal. One thing to avoid is trapping and then causing a loop by using the same signal as the trap is catching. You can unset the trap in the cleanup routine if you run into this problem. A clever bit of *nix-fu to make scripts more like actual runtime applications. Also, yes - placing it after a command is not necessary as long as you are intelligent in the cleanup routine. The one-liner for example would break if the file had not yet been created and then the script was exited. Obviously conditionals inside a cleanup function make quick work of these small problems.

You can also trap unexpected exits and remove that sentinel file in most cases by placing a line like this immediately following the creation of the file: trap "rm -f $temp_file" 0 Certain exits will not be caught by this (kill -9 for example, immediately terminates a process with no regard to any open handles or cleanup code) To explain, the first argument of trap (in quotes) is executed any time the signal to the right is received. 0 is EXIT. Any time SIGTERM, SIGINT etc are fired, you can catch those as well, but eventually all of those lead to EXIT also being called. So if you just need to do something before the script exits, this is sufficient. If there are additional things like wanting to print which signal is received to a log you can do that as well. You can also use this to call a cleanup function, where you could stop any running parity checks, delete the sentinel file, etc.

to my knowledge they only have the nvidia docker runtime (which could easily be packaged) and the nvidia driver blobs (which could easily be packaged into DKMS format) It would reduce the amount of effort required to maintain those builds. I'd approach it, but there's a reason I don't maintain packages anywhere, currently. Not to mention Unraid and limetech's 100% anti-package stance.

Search term: "Molex Punch Down Power 4 pin" https://www.google.com/search?tbm=shop&psb=1&x=0&y=0&q=molex+punch+down+power+4+pin&oq=molex+punch+down+power+4+pin&aqs=products-cc..

Ideally, when just needing to add kernel modules, you would compile just the required modules into *.ko for the purposes of unraid. Otherwise you run into the issues we see above with the monolithic nature of Linux and the fixed versioning of unraid (something I personally disagree with) DKMS would be the ideal solution in the case of the Nvidia build - as instead of installing a new unraid build custom tailored with Nvidia baked in, one could select from available Nvidia driver packages, DKMS would do it's magic and poof you'd have Nvidia kernel modules for the active running kernel. In the case of standard kernel modules - I think we could probably start to approach it like openwrt and other embedded distributions have in the past: Compile the kernel with minimal built-ins to save on memory footprint and distribution size (unraid does this) Compile ALL of the modules as optional packages and make them available through the repository. (nerdpack is our repo, but it'd fill it with a lot of modules) This way if someone runs into a kernel module that they need, which would normally require recompiling a new kernel, they could just grab the package for the module and now it can be added to modules-load.d, or in the mkinitcpio.conf for early loading. Just my 2c from working with embedded Linux distros in the past and seeing how things have been handled there. Here's an example of a set of kmod-* packages for openwrt: https://archive.openwrt.org/snapshots/trunk/ar71xx/generic/packages/kernel/

My problem with OpenVPN is that there is no layer 2 functionality. At least not without limiting the client options substantially. For example, in TUN mode, no broadcast packets are forwarded, hostname resolution and ARP dependent services immediately fail. In TAP mode you gain back the above, but lose your iOS, and (non-paid) Android support. And on ALL clients you must install a 3rd part VPN app to connect, rather than having native OS support. I did not however consider the port limitations. I am currently shoving SSH and SSL through 443 using the SSLH docker from dockerhub to circumvent a restrictive firewall. Perhaps ipsec isn't the end all answer for this... The other questions still stand. I'd ideally like to keep from having to set up a unique user database specifically for this application and my own authentication services. For one that means keeping user credentials on my box, and it also comes with all the headaches of password and user management. Authenticating with an external service and then correlating that authentication token somehow to a user on my box seems like the dream. Let another massive industry player handle the accounts and that headache, let me designate users and their permissions based on that validated identity.

So I'm going to be revisiting my home network soon as my needs, and the needs of users outside of my home network have shifted substantially since the dawn of me having my own network. Currently I'm between settled situations, and will be upgrading and/or replacing the majority of my network by the end of it. Currently users that have SSH access and I have granted the "tunnel" group to are able to open tunnels to ports I specify. This is great for certain things, but for a lot of stuff it's cumbersome, or it just doesn't work - namely hostname resolution doesn't work ever, and neither does SMB or NFS without some substantial doing. For one, I don't like the idea of having tunnel-only SSH users just to open certain applications (though it is quite secure, without their key and their password and all of the correct information, the service is just "unavailable") No do I feel like it's very end-user friendly. Moving forward, I'd like to have ipsec running on opnsense and have remote users just tossed into their own vlan. This saves a ton of headache manually sorting stuff out. The problem is ipsec doesn't do user management - and that's not it's job. Instead I need some sort of authentication service that sits outside of ipsec. I don't want to set up a full blown active directory rollout on Windows Server and arm myself to the teeth just to get some user account management. Ideally, I'd like to use plex-ldap in conjunction with ipsec to enable remote access for users I deem at will. To do this, obviously - I'd need to add an additional ou(s?) to those users (since all users by default exist in ou=users,o=plex.tv) But one this is done, the authentication will be hanled by Plex.tv (or, Google/Facebook, if they use that for their plex account) and I can establish their identity readily based on that information. On to the questions: 1.) Is this feasible? 2.) Is this secure? 3.) Is there a better, or easier way? To exit - let me state that I don't know a lot about LDAP, IPSEC or VPN access outright. I use these technologies to access various systems for work - but I'm not a cybersecurity engineer, and I don't do user management on corporate networks. I just want to make it simpler to enable users access to systems I don't want open to the internet. IPSEC seems like the most widely supported VPN option, currently.

https://paste.ee/p/wcwWV It's posted twice in the last two pages.

You are using the version from the OP. It's broken. I posted a fixed version of the original, but note that its not as effective on Unraid 6.x as the tunables have changed.

I have dual e5-2658v3's. I believe they should be sufficient.

Indeed. I initially looked at this post for a hopeful answer to abysmal parity check times. For me, it takes just shy of 1.5 days to complete a parity check on 24 8tb drives, totalling 176TB with dual parity bringing the raw platters to 192tb. Obvioulsy I have roughly 3 times your surface area. Which should come out to around 18-20 hours of parity check time, assuming similar speeds through and through. 8TB drives are substantially faster thanks to the higher density, and various mechanial and controller improvements. I should be able to read at ~200MB/s off each drive. Thanks to a port expander bottleneck ( Math found the answer - 2 * 4 links = 8 links * 3gb/s = 24gb/s / 24 drives = 1gb/s per drive = ~125mb/s give or take maximum theoretical bi-directional. ) that is not the case. But even knowing that, my speeds are still slower than they should be - around 60mb/s for the majority of the parity check. Something else seems fishy here. Running the script yielded ~10mb/s improvement for me, so I'll take what I can get until I can afford to toss money at the real problem. And yes, the things I want to focus on are outside of the scope of this script - which is another reason I don't want to adopt it as a project. Also; the I/O scheduler has nothing to do with the actual data sent to/from the disk - just when and where that data is sent or retrieved. Unraid is currently shipped with noop as the default scheduler for all block devices. Noop is generally bad for rotational media, as it doesn't do any planning for storing the data contiguously on the platters. This would be suitable for the parity disks, since that data will largely be unorderly anyways. But for the disks storing filesystem data, it can have a negative impact on large file read performance (seeks will occur in large files) and write performance (holes will be scattered, resulting in excessive seeks for writes) over time. It seems like an odd decision on limetech's part. They haven't included any advanced schedulers in their kernel build - so for me to test I'll need lots of time. My plan is to enable DKMS so that nvidia-*-dkms packages can be leveraged (to support more than current-generation only cards) as well as trying to leverage BFQ and/or Kyber. I'll test that on a smaller, non-important box though, when I have the time.

Even then, this is an incomplete picture. Those are just the tunables exposed via the webui. There are more tunables available than that, even most likely. And yes, they do directly change how data is lined up to be written to the array. The latter point about mismatched hardware is why I think a different I/O scheduler could also make a pretty big impact. I believe I read in the past of people switching to CFQ to speed up write operations (currently unraid defaults to noop - which more or less is a hands-off I/O scheduler) something like BFQ could probably mask or mitigate the majority of the IO wait time for different operations. In particular, read operations would probably see a big relief. We also have a new kernel option available in 4.12+ - blk-mq and scsi-mq These are multi-queue options designed for dense multi-disk storage applications to have substantially lower access times. For example, Kyzen scheduler, which is similar in principle to BFQ, but simpler, has shown dropping SSD array times from 8ms to 1ms or lower times. That's a huge impact when there are hundreds or thousands of operations in the queue. I'd have to read more, but I believe at the kernel level, with the old (current) system, the I/O queues are each singular. That meaning, each device in the noop queue, shares the noop queue. Where in the mq implementation, each block or scsi device gets its own separate queue. Meaning increased CPU overhead for command routing, but each device getting more readily available queue handling. This would in theory mean less blocking from varying disk arrangements. A slower 16m cached disk won't be holding back a 10krpm disk with 256m of cache, for example. These sorts of implications are why testing MQ and BFQ/Kyzen are higher on my priority list. I feel like limetech should probably be looking at these options as well - but they are brand new.

Hello! This is also my surface findings from running the old version of the script, the increase is marginal at best - but still worth squeezing any performance out you can. I know that between 3.x and 4.x, the Linux kernel has seen some pretty insane improvements in I/O overhead to begin with, unraid gets to take advantage of that out door. It also means that for a (relatively) old Linux goon like myself, I have a lot of new learning to pick up with what kernel tunables can yield what results. We had a science. That science has changed. I'd also be curious to see how BFQ would affect unraid's performance, including that during parity checks. I can only imagine that BFQ would enable much higher total throughput, at the cost of substantially higher CPU utilization. If I had more free time, I'd play with it... which brings us to the next two points... That's a shame, as that is really what is needed to make this script compatible with 6.x. LT changed the tunables from 5.x to 6.x, and the original script needs updating to work properly with the 6.x tunables. Fixing a few obsolete code segments to make it run without errors on 6.x doesn't mean you will get usable results on 6.x. Indeed, the point was to get something from the script usable with the existing code base and logic - not to create something new. The testing automation ideology implemented isn't fundamentally broken - just the amount of flexibility is. Ideally, one would create a much more in-depth test pattern for a finalized script for 6.x and Linux kernel versions in the 4.x->5.x family. You'd need to find ideal baseline values for several tunables, and then play with those values in tandem to find a suitable combination, since some of these values will impact eachother. I think, looking at the behavior of this script in the real world, and using a bit of computer science, a lot of the "testing time" can be eliminated. For example, performance always seems to be best at direct power of two intervals. We usually see okay performance at 512, with a slight drop off at 640, trending downward until we hit 1024. Knowing this, we can make big jumps upward until we see a decline, and then make smaller jumps downward in value to reach a nominal value with less "work" Obviously this would be great for getting initial rough values quickly. Higher granularity could then be used to optimize further. There's probably some math that could be done with disk allocation logic (stripe, sector, cache size et al) for even further optimizing, but that's a pretty large amount of research that needs to be done. I actually don't know what tunables are available currently (It's not hard to dump them with mdcmd) or what their direct impact is on various workloads. That's another shame. Seems like you know what you're doing, more so than I do with regards to Linux. I'm a Windows developer, and my limited experience with Linux and Bash (that's what this script is, right?) is this script. For me to pick it up again, I have to essentially re-learn everything. I keep thinking a much stronger developer than I will pick this up someday. I'll take the compliment. I'm still ever-improving. I'm an amateur developer, but I have many, many years of experience with Linux as a platform, including building automated install suites for various distributions (though Arch is probably the most friendly for this type of application). And various performance tuning for other applications, specifically low-latency gaming applications related to rhythm-games. You'd be surprised how much it is possible to optimize each step of the chain when you really dig into it. Unfortunately, life has sucked all of my free time away from me. I want to spend more time focusing on projects like this - I just don't have that time available. Spending an hour or two while I'm sick fixing a script is affordable, spending a couple of hours a day for several weeks designing and implementing a replacement isn't an option yet. It's interesting that even though the two tunables the script currently tests are not as relevant today, there is still a fairly substantial performance improvement available using them, though. No, it won't shave hours off your parity check, but it will make the difference between saturating gigabit connections and not. In my case, I have a bottleneck upstream that caps my parity check speed around 70mb/s Once I get rid of this slow port expander...

You aren't running my script. If you do a ctrl-f on my script and type "/root" you'll see there is no hard coded reference to that location. Your output is also showing: "unRAID Tunables Tester v2.2 by Pauven" I've added to the end of that and it should read: "unRAID Tunables Tester v2.2 by Pauven - MOD by Xaero" Both of these changes were intentional. One was to help differentiate, the other was because we shouldn't be using a hard coded nonstandard path like /root.

The forum may be mucking it up for us, let me post a link from a sane paste site. https://paste.ee/p/wcwWV Some quick notes for the curious for some decisions: Each call of echo actually eats CPU and I/O scheduler time, even the ones that only write to the screen. It's better to produce many lines of output with a single echo or cat statement generally than to use many. I left some of these in just to avoid frustration with implementing a single echo that did the same thing. In some places I've opted to use cat. This happens in two circumstances: 1.) Where there's identations. A CR escaped echo `echo "\` prints identations literally. You could use a heredoc with echo, but it can be unpredictable depending on what implementation of echo is present on the target machine. It's easier, and safer in this circumstance to use `cat` 2.) Where there's bash sentinel characters `*` for similar reasons as above, if you use a cr escaped echo to print a block that contains a bash sentinel, it will expand those sentinels. To work around this, you can temporarily turn off this processing, and then turn it back on with `set -f` and `set +f` respectively. This is 3 separate calls to do what a single cat handles with no problem. cat can be measurably slower in certain circumstances, but its generally negligible, especially since we've reduced the number of calls 3 fold. You'll also notice I use two different heredoc sentinels with cat, `<< EOF` and `<<-EOF` the former includes whitespace to the left of any text, and requires that terminating EOF sentinel to rest on the first character and be the only character on the entire line at the end of the heredoc. While the latter truncates anything whitespace located to the left of the terminating EOF sentinel, and allows whitespace to preceed the terminating EOF sentinel. In this manner I can retain identation on appropriate text blocks without including it in the resulting output. The other changes are not preferential but agreed upon by most of the industry as "proper syntax" ( `$()` for command substitution in lieu of ``, double quotes around variables to prevent globbing, etc.) I didn't bother messing with the logic as I wanted the script to retain its original functionality, and just have more longevity. Currently no errors should be output during a FULLAUTO run, from my test earlier today. If you run into an error message ping me here and I'll see what I can do for now. I don't plan on adopting this project, just don't like seeing hard work lost or error messages on my terminal windows. (I suppose I could just wrap everything with a 2>/dev/null) PS: I've been very ill, so I've made a substantial number of typographical errors in my notes and comments in the script. The script runs okay, as I had to test it - but trust me, it didn't run the first time I tried after making all of the changes. Not even close. Hopefully my brain starts to pick up speed again over the next several days.

Attached is a debugged version of this script modified by me. I've eliminated almost all of the extraneous echo calls. Many of the block outputs have been replaced with heredocs. All of the references to md_write_limit have either been commented out or removed outright. All legacy command substitution has been replaced with modern command substitution The script locates mdcmd on it's own. https://paste.ee/p/wcwWV

Good evening! I'd like to not only request this as a feature, but explain how one could implement this on their own! Basically, the idea is that all user customization done via configuration files located in "/root" are lost on each boot. I know this is intentional, but there's an "easy" way to implement this with clever failsafe mechanics. I also know that one can work around this by adding a couple of lines to /boot/config/go, and storing the configuration files on the flash drive. This isn't as desirable as Fat32 doesn't properly handle Linux permissions, and can require other manual edits to the go file down the road. Enter OverlayFS (a feature built into the Linux kernel for eons) First we create the container for our data. I use the truncate command as it is safe and "quick" (note: we are writing over USB so this step will take time no matter which option we use) truncate -s 4000M /boot/config/root.persist I chose to go with 4000M as it is close to the Fat32 ceiling of "4gb" (note: if you specify 4G you will receive an error) Next we format that image, and set up some important directories within it: mkfs.ext4 /boot/config/root.persist mkdir /tmp/overlay mount /boot/config/root.persist /tmp/overlay mkdir /tmp/overlay/upper mkdir /tmp/overlay/workdir Finally the special sauce that overlays the image we created on top of the normal unraid /root/ directory: mount -t overlay -o lowerdir=/root,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/workdir none /root Anything written to /root/ after this command is run will actually be writting to /tmp/overlay/upperdir, and permanently stored there. The lowerdir will never be modified in this situation as it isn't addressable since we are placing the overlay on top of lowerdir. And to make it persistent, we add this block to /boot/config/go: if [ -f /boot/config/root.persist ]; then mkdir /tmp/overlay mount /boot/config/root.persist /tmp/overlay mount -t overlay -o lowerdir=/root,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/workdir none /root fi A couple of notes: The if statement above makes sure that we don't try doing anything if there isn't a persistent image for the root folder. It's kind of redundant (the first and second mount commands will just fail and regurgitate errors if the file isn't there) but I prefer a clean console log. If the image becomes corrupt, or unusable you can safely discard it this way. Safe mode shouldn't use /boot/config/go so if anything goes wrong safe mode will undo any of the changes contained in the image. Meaning you can boot into safe mode, manually mount the image, and undo whatever you did in upperdir and be back up and running. I'm not sure what you could do to cause those sorts of things. This also allows for: Persistent bash history (forget that command you ran before you rebooted? No more.) Persistent config file storage (tmux preferences, terminal colors, and htop profiles? Oh my.) Persistent KNOWN_HOSTS and AUTHORIZED_KEYS for ssh. Anything you would normally want a home directory to be useful for in LinuxLand.

I kind of regret paying for a plex pass, honestly. Emby seems like the development team is not only more active, but more responsive.