T0rqueWr3nch

While preparing to shrink my array, I had a question which I didn't see documented on the wiki or in @RobJ's zeroing script post. If we are zeroing the data disk, shouldn't we disable the mover? Otherwise, don't we run the risk of data loss if the mover runs and moves data to the disk being zeroed?

Can you help me run through the following scenarios? 1) Parity 1 fails- This one seems obvious. Data drives are still intact, let parity 2 run through to completion. 2) Parity 2 fails- Parity never existed on it in the first place, so who cares. But the loss of a data drive seems less obvious to me: What happens if a data drive fails? Does the parity 2 rebuild continue to run or does it stop automatically? If it doesn't stop automatically, aren't we just now calculating parity 2 with a corrupt disk thus corrupting parity 2? Do we stop the parity 2 calculation? Do we go back in to the New Config and remove Parity 2 from circulation, check the "Parity Already Valid Box", restart the array, stop the array again, power down, pull the failed data drive, install new data drive, power on, assign new data drive and rebuild the data drive? Sorry for the barrage of questions; I really value your input.

That's a good suggestion. So split step 3 into two phases: 1) After zeroing, save new config with zeroed data drive removed and "Parity is valid" checked and then 2) Save New Config again but with the removed drive set as parity 2. Parity 2 (and only Parity 2's) contents rebuild. Do I have that right? Now let's talk emergency/recovery procedures: In the event that I have a drive failure while Parity 2 is rebuilding, what would be the best procedure from here? I like have contingency plans in place. This is why I have already taken two backups: one offsite and one rsync'd to an external drive, but the answers to these questions help me build a model in my mind of how Unraid works so I can respond without a flowchart (and it may be helpful for other users in the future). Thanks again!

So I have a large surplus of storage space that I likely will never use (<1.5% utilization). Because of this, I'd like to remove one data disk from my array and use it as a second parity drive. My plan is to do the following: 1) Migrate drive contents to the other data disks using unBalance. 2) Zero drive with the script found here: Additional Scripts For User.Scripts Plugin - Plugin Support - Unraid 3) Stop the array and create a new array configuration. The (now zeroed) data drive will be removed from the data pool and added as the second parity drive in the same step. Main Request: 1. Can someone please review this for accuracy/safety? Secondary Questions: 2. Keeping in mind that I am adding a second parity drive where parity has to be rebuilt, does this zeroing step help me at all? Would I still be protected by the first parity drive while parity is being rebuilt? 3. I assume I cannot check the "Parity is already valid" box because, even though it is for the first parity disk, it isn't for the new second parity disk, correct? 3. Has anyone done this before? Thanks in advance!

OS updates (IIRC) come from AWS. Best of luck keeping track of those. Do you have a specific concern with allowing Unraid to initiate the outgoing connection and then allowing the established return traffic?

Hey everyone, I recently had a permissions issue where an rsync backup failed to an NFS share in Unraid. It ended up being due to an ACL on that particular directory (and in fact it's on the whole share). I won't rule out that something outside of Unraid itself accessing that directory didn't set it, but is anyone else seeing something similar? Seems to be new since the latest RC, but that could just be a coincidence. Thanks in advance!

It's an excellent point. Unfortunately, I don't think there's going to be anyway around checking in layers since none of these checks are going to be absolutely foolproof. There's just too many that the library can be hidden/obfuscated. That's why I recommend following it all up with the scan at the end even if the other tests come back negative. If it's positive, then you know you're affected, and if it's not you can at least be reasonably confident that you aren't. And then you're also not relying entirely on the developer/Docker maintainer that may not even be aware of the dependencies they're using themselves. Can I get your opinion on something? I am considering replacing step 1 ("the quick and easy way") with an even quicker and easier way that has a few more automated checks. The problem is that it uses a remote script: wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | bash I trust the remote script, it's clearly visible what it's doing and it's basically doing the same checks (but automated and includes your Java install check), but what is your opinion on recommending this to other Unraid users? Would you yourself be comfortable with it?

It's a good starting point so I should probably at least mention it, thanks. By itself though isn't completely accurate and thus not sufficient to check for vulnerability:

For what it's worth, I wrote a quick guide on testing your Unraid server + Docker containers against the log4j/log4shell vulnerability if you want to independently verify. Log4j for Dummies: How to Determine if Your Server (or Docker Container) Is Affected by the Log4Shell Vulnerability The guide is still very much a work in progress as the situation is evolving, but when tested against a container with known vulnerabilities, it flagged it as such. In the interest of getting a guide in yall's hands as soon as possible, I prioritized testing and writing the guide. As a result, I have not yet created any templates for Community Apps (let me know if anyone would like to collaborate with me) and so you'll have to deploy the scanner container manually. Any feedback or additions anyone would recommend to the guide would be very much welcome. -TorqueWrench

Nope, I haven't noted any ill effects so far. Unraid's umask seems to be set to wide open (checked by running umask -S which returns 000), so I really don't understand what could've changed. Reviewing this stuff does make me wonder again if I should be doing more for ransomware protection...

That's what I ended up doing right after I posted that! Glad to have the independent verification. Thanks! Honestly, I'm not sure why this hasn't always been a problem- rclone says its default umask is "2", but other sources say this is really 0022, which is what I'm seeing. I wonder what changed with rc2. Could it be related to this "Fixed issue in User Share file system where permissions were not being honored."? Unraid OS version 6.10.0-rc2 available - Prereleases - Unraid While troubleshooting this, I also used this as an opportunity to update how I mount rclone. I passed the uid and gid arguments to mount as "nobody" and "users" (UID 99; GID 100). I might go back to just mounting as root again. Thoughts?

I'm having the same problem, "Group" and "Other" are both missing write permissions. Started with update to rc2. Unfortunately this didn't work for me. I assume you added these arguments to the rclone mount command? This feels like a umask issue...

Don't know what to tell you- it doesn't work for at least two of us...Not sure what setup differences we have to account for this but that script works fine for us.

Script definitely works as I've been using it since June when I ran across this issue. In contrast I can personally attest that fusermount -uz does not and as reported by another user here:

I forked the repo and submitted a pull request to fix the unmount script. You can see my proposed unmount script here: https://github.com/Torqu3Wr3nch/unraid_rclone_mount/blob/umountFix/rclone_unmount

Configuration stored in /etc/rc.d/rc.nfsd changed with Unraid 6.10.0-rc1. nfs_config() should be updated to: nfs_config() ( set -euo pipefail sed -i ' s/^#RPC_STATD_PORT=.*/RPC_STATD_PORT='$STATD_PORT'/; s/^#LOCKD_TCP_PORT=.*/LOCKD_TCP_PORT='$LOCKD_PORT'/; s/^#LOCKD_UDP_PORT=.*/LOCKD_UDP_PORT='$LOCKD_PORT'/; ' ${DEFAULT_RPC} sed -i ' s/^\s\{4\}\/usr\/sbin\/rpc\.mountd$/ \/usr\/sbin\/rpc\.mountd -p '$MOUNTD_PORT'/; /if \[ \-x \/usr\/sbin\/rpc.mountd \]/ i RPC_MOUNTD_PORT='$MOUNTD_PORT'; ' ${RC_NFSD} /etc/rc.d/rc.rpc restart sleep 1 /etc/rc.d/rc.nfsd restart ) The above should cover both 6.10.0-rc1 while still keeping compatibility with prior versions.

So just a follow-up for at least question 1: I DO NOT recommend using /mnt/user0/mount_rclone. I wanted my cache to be a real cache (i.e. to use the Unraid cache drive), but I also wanted to be able to move it to disk if I need to clear up space, so instead I went with /mnt/user/mount_rclone with the mount_rclone share set to use cache. As for question two, I still haven't thoroughly looked into why the upload script is necessary when using rclone mount. I believe the reason is because we're using mergerfs and when we write new files to the mergerfs directory, we're physically writing to the LocalFileShare mount and not to mount_rclone itself. Therefore the upload script is necessary to make sure any new files get uploaded. Any pre-existing files, if modified, I'm willing to bet are actually modified within the rclone mount cache and handled directly by rclone mount itself.

Another few questions myself: 1. RcloneCacheShare="/mnt/user0/mount_rclone" - Is there a reason this "Rclone Cache" isn't using the cache and is using spinning rust directly instead? Should this be /mnt/cache/mount_rclone? I saw a similar question asked in the past 99 pages, but never saw a response. 2. If we're using VFS caching with rclone mount, why do we need the rclone upload (rclone move) script? I have noticed that sometimes when I make a change, it's transferred immediately (even though the upload script hasn't run yet) and other times, the upload script seems to have to do the work. Any idea why? Thanks.

I'm wondering the same thing; and I'm wondering how much of this is dogma. I also don't know why it would need the root /mnt/user instead of the more conservative /mnt/user/merger_fs (which I would still not be a fan of since I assume most of us are going to be compartmentalizing that directory further). My only guess as to why their might be a difference is if rclone can share a connection if the root directory is mounted, instead of having to reestablish a connection to the Cloud service for each individual subdirectory request, but I readily admit ignorance of rclone's mechanisms.

It's been that way for as long as I can remember, but then again I've been on some form of 6.9rc for as long as I can remember...ha.

Keep advocating for Unraid R&D to implement NFS v4. That's your best bet. (Or go iSCSI).

I had the same problem, though I think the writes are technically coming from MongoDB which Tdarr uses: I just disabled Tdarr and MongoDB until I need them, which isn't ideal...

Hey Nick, That's not what we're complaining about. We're complaining that the size of the container itself is so large. 1 GB containers are unheard of. Over 5 gigs? That's astronomical.

I used to love tdarr and even did some of the testing for it before it was released to CA on unRAID. This past weekend, I updated my container and started to get Docker disk space warnings. My jaw dropped when I saw the size of Tdarr after the latest image pull: tdarr is now over >5.5 GB! This is the alpine version, not even the Ubuntu OS base. Even at that, we're now looking at an image that's larger than a full Ubuntu GUI desktop OS install. Edit: Actually, it looks like the image uses an Ubuntu base by default, regardless of what Community Apps says. When did we lose our minds? -TorqueWrench

Do we have an ETA on when unRAID will support NFSv4+? I've seen this request come up multiple times on here, and it looks like at one point, Tom even "tentatively" committed to trying to "get this into the next -rc release": Unfortunately, that was over 3 years ago. Do we have any updates on this? I believe adding support for more recent NFS versions is important because it is likely to resolve many of the problems we see with NFS here on the forum (especially the NFS "stale file handle" errors). I think that's why we also keep seeing this request come up over and over again. I understand where Tom is coming from when he says, "Seriously, what is the advantage of NFS over SMB?": The majority of the time, for the majority of users, I would recommend SMB. It's pretty fantastic as it exists today but, there are times when NFS is the better tool for the job. Particularly when the clients are Linux-based machines; NFS offers much better support for Unix operations (i.e. when you're backing up files to an unRAID share and it contains symbolic links). NFS also offers better performance with smaller files (i.e. those short, random-R/W-like file operations). Rereading my post, I hope this request doesn't come off as overly aggressive. That's certainly not the intent. I just wanted to provide some background on the request and advocate for continued NFS support on unRAID. NFS is still an important feature of unRAID. Thank you in advance for your consideration! -TorqueWrench