aqua

Most of the apps aren't giving meaningful error messages. Maybe unraid is logging something, but I'm not actually sure where to check for that. Tried checking the syslog but didn't see anything at all, but I don't really use the logs so maybe I'm not set to log things it needs to. Edit: Also getting permission errors with cut/paste with most android file managers... *sigh*

Maybe - I've never added anything there before. I wonder if apps need to be updated to be able to work properly with newer versions of samba and perhaps most aren't updated yet. Really weird. Edit: Discussed with a user in the discord and they also had the same thing happening to them in that File Manager+ for android worked properly but others gave errors but still deleted the app. I'm assuming that this is something app devs need to update and not really on unraid side.

Yes, 100% sure. The permission issue arises even in public folders when using anonymous users or named users. Again, the file DOES get deleted, these apps just say there is a permissions error and that they can't delete it. It is very weird. I included a screenshot of the error above as it was more informative than other apps which were giving the error.

My main device is a oneplus 8T on android 12 but, again, I've tried this on several different phones. I've also used different file managers and three of them give errors but one of them didn't (very interesting). I've also emailed the dev of one the main file manager I use to provide as much info as I can, including your information on the new samba versions. As for my use case, I just download some things manually and then manually move bits and delete other parts. I'm not aware of unraid having a trash, but that isn't really what I'm looking to do anyways, and would require more work/steps than just deleting a file. I do suspect the issue is at the app level, but perhaps samba itself is in the phone system and not the app and the app that works is just suppressing the error message...

@Frank1940 @kizerOK, updated to 6.11.0 again and issue remains. I've attached the screenshot of the ls -al /mnt/user command. I'm still unclear exactly how the fix permissions should be executed: do I include all drives and all user shares? not include the cache drive? Not include the appdata folder? I had some files in the Test share that I was using to test deleting files so I ran the new permissions script on just that folder that and still have the same issue. Thoughts on next steps? I'll add that I've noticed I can cut a file and move it to a different place without issue, just getting the issue when trying to delete. Part of me wonders if it is a samba change from what was in 6.9.2 and the file managers I'm using aren't updated for the samba changes.

@Frank1940 Thanks for your reply but I'm a bit confused as to whether you are suggesting that the "New Permissions" is the script to potentially fix my problems or not. I'll note that the file deleting error wasn't just with existing files - i could create new files from windows or android phones (users and guests) and when deleting the files only the android devices had issues. To be clear, I don't need to know what the scripting looks like, just to be sure that I am trying the right thing, so if we think that the "New Permissions" is the potential solution, am I running that on all drives and user shares (but deselecting appdata?) - I'm on 6.9.2 so perhaps I'm not seeing what the versions in newer releases have. I am willing (and wanting) to update to 6.11.0 again, but need to know how to then deal with the issues, knowing what to try next... I do really appreciate your response though.

What script are you referring to? I'd love to be able to test it out asap after an update.

@Frank1940 @kizer I can give it another go and do the update again if we can resolve the issues. I had heard of some people having permission issues but this was weirder than I thought - no issues on windows, failure messages on android (which has be solid before when windows was sometimes buggy) that then still performed the task they said they didn't perform. I can run that command from terminal but with regard to changing things to 777, wouldn't that have been done by the docker safe permissions fix?

I already went back to 6.9.2. I did look and shares etc were owned by "nobody" if that is what you were looking for with that command, though if i created a file with my named user login it would show it was created by that user, though it was affecting files created by my user and also non-users/guests. I had rolled back but then had to restore from my backup as the disabled wireguard and dynamix ssd trim plugins were still deleted when I rolled back, and even though I then deleted the ssd trim one and reinstalled it the actual trim options didn't show back up in Scheduler. Frustrating - I held off trying 6.10.x and tried 6.11 because I wanted to keep the "My Servers" working, but I didn't expect issues like this.

I just updated from 6.9.2 to 6.11.0 and when I'm deleting files off of shares from my android phone using a file manager there (and I've tried more than one) I'm now getting errors that "Permission is denied. No item deleted." but when I refresh the folder the item IS deleted. Happening in private, secure, and public folders but does NOT seem to be affecting deleting files with windows (what world is this that android is affected but not windows). No idea what is going on here but didn't experience this before with 6.9.2. I've tried multiple phones that previously didn't have issues and also creating files with an actual user and a guest (so the file ends up shown as owned by either myusername or nobody. Any thoughts? I've run "docker safe new permissions" just in case but it didn't change anything. Edit: I rolled back to 6.9.2 and issue went away. What in 6.11.0 would affect this? I'd love to update, but need to be able to manage files by my phone.

Yes, was/am running 2021.04.20. I noticed yesterday that when I was checking settings, before changing to a percentage to make things run, I think I had tried setting by age and had a weird thing where if I had it on "No" then I could select the number of days but if I had it on "Yes" then that selection was greyed out. Anyways, it is working on 0% now when I tested it so I guess things are back to normal, though I don't know what the issue was. So I am clear with the tuner, the mover settings schedule (set to daily) just invoke the mover and then the mover tuning settings get looked at to determine whether mover does anything, right? As I'm set now, I just want it to run ever night and move everything off the cache (except cache prefer) which is why I have things set to 0% and everything else set to no (except allowing mover to run during parity check/rebuild). I think I had logging on for a bit when it wasn't working, but then disabled it later - would the logs for that still be available? I can try to dig them up if they would be useful - though I don't know that I've looked at logs before and am not immediately sure where to go to grab them.

I am on 6.9.2 and recently noticed that my cache drive was filling up and that mover wasn't doing anything. Mover tuning had pretty much everything set to "No" and the "Only move at this threshold of used cache space" set to 0%, but nothing would move. Didn't get anything to change until I set this to an actual percentage (I chose 30%) then ran mover. Is this a bug? I have been using for years without changing settings and not having errors.

When I was setting up the docker profile I had changed "/output" to "/OUTPUT" and then none of the files I encoded showed up. I figured out the problem and changed it back and new encodes show up, but where would the old ones have gone, so that I can go and delete those files?

DISREGARD. I THINK THIS IS AN ISSUE WITH THE UNASSIGNED DEVICES PLUGIN. I've been running a preclear on two drives at the same time, one that is on a LSI card that is new to me and the drive on it disappeared from the unassigned devices list on the main tab of unraid midway through the test, but still finished fine and still shows up when you use the "-l" command, and will confirm the preclear finished when you run the "-t" command. The other drive is still going (must slower it seems, though they are both the same model) and is still listed, connected to the motherboard intel controller. I posted about this in the main unraid support forum, as I don't expect this is a preclear issue, but in case it is, thought I'd mention it here - not sure if that LSI card is suspect or what... here is that post. Edit: I note that the "-t" which confirms it was precleared is states the size as "2T" in the table it spits out - I can't test against the other drive right now to see if that is normal, for anything 2TB+ or if that is unexpected.

I connected two new (old to me, but haven't been used with unraid) 8TB drives through my system and was running a preclear (via the docker) on them: "sdb" was connected to a new LSI card that I got (ie: haven't used before - this preclear was intended to be part of the test) and "sdg" which is connected to the intel controller on the motherboard. The sdb drive disappeared from the unassigned devices list on the "main" tab in unraid midway through the preclear, for some reason, but it still finished successfully, and it still gets listed when I run the "preclear_binhex.sh -l" command, and the "preclear_binhex.sh -t /dev/sdb" command will still read it and confirm that preclear finished on it. The sdg drive is still listed but hasn't finished yet and was/is going significantly slower. I haven't rebooted or anything (since preclear is still running on sdg) but I'm not sure whether I need to be concerned about the LSI card ( LSI-9200-8i from China off ebay) or if this just sometimes happens - obviously I wouldn't want the drive dropping out of the array. Any thoughts?

Just to update this, removing the molex to sata adapter that was in place and using the power supply cables and issues went away. Ran another parity test and had errors that got corrected (uncorrected due to issues from before) and then a subsequent parity test without issues. I don't actually think it is the cable but more likely that the power supply deteriorating and no longer being able to handle all the drives spinning up at once on the one rail. I'm moving to another case anyways, so I will be putting in a better/bigger power supply. Thank you for your support, @trurl - I think it would have taken me a long time to suspect power might have been the issue.

Hmm. I tried a few things and so far what seems to have worked was taking out the molex to 5x sata splitter (only connected to 4 drives) that I had the drives running off of and having them powered straight off the sata connections from the actual power supply (I'm down to enough drives that I can do that now). Not sure why that would be the issue all of a sudden, but so far it seems that may have been it. Will do more testing.

Oh, OK. They aren't bundled but the case is kind of tight - never had an issue before now though. I'll unplug and replug everything. yeesh.

I've unplugged sata on both sides, though didn't do power on both sides and plugged in again. what does bundling sata cables mean? Things seemed OK but I will take apart again and see. I've confirmed that he ports I'm using are the intel ports.

I am using the same ports. I think there is an additional 4 ports on another controller (has 10 onboard) but I'm not using those - using the main ones. Motherboard dying?

I started a parity test yesterday and it just finished, with 97238 errors!!! I am not seeing any problems in the smart data and I ran a short test on each drive and they all passed. I am also noticing lots or errors and warnings in disk log information. Not sure what to do or how to approach this now - can anyone point me in the right direction? It has been 100+ days since the previous parity test, but that one completed without issue. Since then, I have moved homes, so maybe something happened in the move? Really appreciate any help anyone can give. I've attached diagnostics zip file - hopefully I've done that right. After getting diagnostics file I shut down, unplugged and replugged all sata connections and have started some long smart tests. I check disk log info and parity drive is showing some errors, as is another drive. sigh... tower-diagnostics-20200902-1913.zip

High-water Choose the lowest numbered disk with free space still above the current high water mark... The above is from the help - meaning that the fill goes in disk number order, which is why I was thinking I should have my largest drives first, but that might be not really a big deal. I'm still confused as to the whether I would need to use "new configuration" - isn't that just for multiple drive adds or removals? Couldn't I just swap the drive allocations around after stopping the array and then rebuild parity?

Disk order impacts the order that the allocations will fill up said disks - but maybe it doesn't matter enough to worry about it. I was thinking I would want my largest disks (8TB x2) to be disks 1 and 2 and my 5TB to be disk 3 and my 4TB to be disk 4, but maybe this isn't totally worth dealing with. If I choose to do it though, I still want confirmation of how I should be doing it. Thanks.

Looking for some confirmation before I do something wrong: I had an 8TB drive as a parity drive but got a new 10TB drive and put it place of the old drive and parity is now rebuilding. I want to add that old 8TB drive to the array, which should be simple enough, but have a few questions: 1) I assume there is no point in preclearing a drive that was working fine in operation for several months, right? 2) I was thinking I'd like to add the drive and then start making better use of the split levels, and would likely want to reorder my disks as I have some smaller ones ahead of it in the disk order. Is there anything special to do for this? Do I need to add the drive and then move them around in one step, two steps? From what I understand, the "new config" isn't what I'm after (though I am confused as to when it would be used to add multiple disks at a time - wouldn't that destroy parity?) and that I would just stop the array and move drive orders - right? Also, to confirm, drive order is tied to serial number of the drive and not the connector the drive goes to, right? I should be able to move drives to other ports (including expander cards (not the ssd cache though)) anywhere without consequence, right? With dual parity does that change?

Also having this issue, only with linuxserver repositories.