Permission errors in 6.11.0 when deleting files from phone with android file managers

[aqua]

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.

Edited September 23, 2022 by aqua

[Frank1940]

Please post up the results of the following command:

ls -al /mnt/user

 

[aqua]

31 minutes ago, Frank1940 said:

Please post up the results of the following command:

ls -al /mnt/user

 

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.

[Frank1940]

I wanted to see the permissions on the shares and the directory---   /user/   ---as these have been involved in several cases of access difficulties in the past couple of weeks.  The symptoms were always that the an upgrade from 6.9.x to 6.10.x would result the loss of access and a rollback would 'fix' things... 

Edited September 23, 2022 by Frank1940

[kizer]

@Frank1940

 

Yep, I've seen a few people complain about the same thing on Reddit. Seems to be some kind of weird instance, but at least there is a fix changing it to 777

[aqua]

@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?

 

[Frank1940]

2 hours ago, aqua said:

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 really don't think so based on the experience of the other users.  As I recall from the discussions at the time, the script was written to run on the physical disks.  (In fact, it was intended to be run only once when the server was upgraded from version 5.X to version 6.X as-- I believe ---, root was the owner and possibly even the group name in version 4 and version 5.)

Edited September 24, 2022 by Frank1940

[Frank1940]

One more thing, I believe the permissions are wrong in version 6.9.X but for some reason, it works.  (Samba was upgraded between the two versions and there were a lot of CVEs that were addressed in the updated samba version used in the ver 6.10.X.  One of those security updates could be the reason for the problem as the permissions are definitely wrong on 6.9.X!)

 

Why do I say that?  The vast majority of people make the upgrade from 6.9.X to 6.10.X without any problems.  Only a few people have the problem.  When they revert back to 6.9.X, the problem is gone.  If they upgrade again, the problem comes back.  So it appears that the permission error in 6.10.X is an inherited set of permissions from the 6.9.X installation.  To date, no one has identified what is changing these permissions but it reasonable to suspect that some Docker container or Plugin is the culprit.

[aqua]

1 hour ago, Frank1940 said:

I really don't think so based on the experience of the other users.  As I recall from the discussions at the time, the script was written to run on the physical disks.  (In fact, it was intended to be run only once when the server was upgraded from version 5.X to version 6.X as-- I believe ---, root was the owner and possibly even the group name in version 4 and version 5.)

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

[Frank1940]

9 hours ago, aqua said:

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

It is still in the current releases (haven't check version 6.11.0 yet).   You can find it   Tools    >>>   New Permissions   (It was revised when a problem was found that it would reset things in the appdata share and to add some additional functionality to it  You can read about this if you just open up the tool.   Note that it only works on Disks and Shares.  You can verify this by looking at the options of what can be selected to to worked on.   Specifically, it does NOT list that it will modify the   /user/   'device'!)  

 

Docker Safe New Permissions was developed for use in the interval when the New Permissions script was causing problems.  Both scripts do basically the same thing.

 

The problem with Windows access was caused by the wrong permissions on the   /user/    device!    At this point, we don't know what the cause of the problem is Android Devices.  Hopefully, it is a permission error!

 

I don't where either of permission fixing scripts are located in the Unraid file system.  I am sure that they are scripts because no good Unix/Linux programmer would use anything like a C++ program when a Shell script will do the job!  (Unix was build on the concept that the shell language would be the backbone for most system utilities!)

 

If you want to see what a shell script looks like, download the first Preclear script from the first post in this thread:

       JoeL. Preclear Script

Don't try and run this script as there are some commands in it that are not in the current versions of Linux.

[aqua]

@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.

[Frank1940]

You can run either of the scripts and see if it will fix the problem.  Prior to this recent outbreak of access issues, that was the first step.  And it worked often far more often than not!  (To be be fair, it was not always the solution to the what was causing the problem but it fixed the damage caused by the problem temporarily.  Then an investigation would have to pursued to find and correct the application that was generating files with the wrong permissions/owner/group and fix that issue.)   

 

Understand that this is the first instance of the problem with an Android device that we have heard of.  So what the problem is, nobody knows at this point.  (In fact, you have not even told us what version of Android your device is using.)   No one knows where we should be focusing.  You were asked about the information on the /mnt/user/ mount point because we have found that it was the permissions at the point were wrong on the server and when corrected, that fixed the problem for Windows 10/11 computer access.  Obviously, the proper permissions should be verified and set up on the server before we start looking elsewhere for a solution!

[aqua]

@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. 

Edited September 24, 2022 by aqua

[Frank1940]

The permissions on this screen are what we would expect them to be.  So the problem is not there.

 

2 hours ago, aqua said:

Part of me wonders if it is a samba change from what was in 6.9.2

In Unraid 6.9.2, the samba version is  4.12.14

In Unraid 6.11.0, the samba version is 4.17.0

 

I leave it to you to figure out what has changed.  (I am a volunteer and I don't intend to devout that much time to such a task...)   You will have to start here:

     https://www.samba.org/samba/history/

Don't really recommend that course of action...

 

You should be starting by googling  using such terms as---  Android, smb, problems  ---and see what you find.   

 

As a complete aside, why is it necessary for you do file management on your Smartphone?    Why don't you try 'cutting' the file and 'move' it to 'Trash'?   How old is that Smartphone and what version of Android is it running?  Is your carrier even updating it still?   I would be investigate these types of questions as the problem appears to be on the Android side of the equation. 

[aqua]

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...

Edited September 24, 2022 by aqua

[kizer]

Now are we sure its passing the correct user name to unraid to allow file deletions?

Permissions are tighter in 6.11

[aqua]

25 minutes ago, kizer said:

Now are we sure its passing the correct user name to unraid to allow file deletions?

Permissions are tighter in 6.11

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.

[kizer]

The only thing I can think of right now is 6.11 uses a different version of Samba that 6.9.2 uses. 

I wonder if something needs to be placed in smb-extra to make it work. 

[aqua]

1 hour ago, kizer said:

The only thing I can think of right now is 6.11 uses a different version of Samba that 6.9.2 uses. 

I wonder if something needs to be placed in smb-extra to make it work. 

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.

Edited September 25, 2022 by aqua

[kizer]

Could very well be. Or if the guys at limetech had a bit more info maybe they could shine a little more light on the subject as far as what a fix could be maybe even a tweak on your system.  Problem not knowing what the problem is its hard to address.  Does your logs show anything either on the app or unraid. I know you posted a screen shot, but is there anything else?

[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*

Edited September 25, 2022 by aqua

[aqua]

So I've been in touch with a developer of one of the apps that I am having an issue with and they aren't getting issues with Samba on Ubuntu. This is what they said:

Quote

 

Finally I had the time to test this: I have compiled and installed Samba 4.17.0 from the official Samba sources now on Ubuntu 22.04 LTS. Then I have created a small sample server and placed some files on the share. I did NOT get any errors when deleting these files with my LAN plugin. I tried connecting via SMB1, SMB2, and SMB3, plus SMB3 with encrypted transfers. The files were just deleted without issues.

 

 

I'm really struggling with this as it affects my ability to remotely manage files from my phone. I'm on 6.11.1 now but same issue persists. I've chatted with another person on discord that is getting the same issues - not sure if this is an unraid issue here or what but, again, it is really changing how I do things. Any thoughts @ljm42?

Edited October 20, 2022 by aqua

[ljm42]

Perplexing. Can you give me a link to the app in the Google Play store? And then the simplest set of steps you can think of for reproducing the problem?

[aqua]

@ljm42 There are several apps that don't work and a few that do. See this youtube video [edit: removed video] of me going through some of the apps and showing the errors and then the file deleting (generally just the first file if I have selected multiple). As for reproducing this, I'm experiencing this just when trying to delete files from a SMB share from any of my android phones, regardless of whether in a private or public share - I made a bunch of txt files as tests, as you can see in the video. 

 

Non-Working Apps (which all worked on 6.9.2 and previous):

• MiX Explorer: https://play.google.com/store/apps/details?id=com.mixplorer.silver
• Solid Explorer: https://play.google.com/store/apps/details?id=pl.solidexplorer2
• Total Commander (this was the dev I was in contact with above): https://play.google.com/store/apps/details?id=com.ghisler.android.TotalCommander
• Material Files: https://play.google.com/store/apps/details?id=me.zhanghai.android.files

Working Apps:

• File Manager Plus: https://play.google.com/store/apps/details?id=com.alphainventor.filemanager
• Cx File Explorer: https://play.google.com/store/apps/details?id=com.cxinventor.file.explorer

I'll note that while File Manager Plus works to delete, the other apps like MiX Explorer would allow immediate moves between shares if I was browsing through the same folder path (like Krusader does) whereas copy/paste with File Manager Plus will move the file but will actually copy it over to move it. While this share is public and I've tried with phones that are logged in to a user profile as well as ones that aren't, it is possible that this is a permissions peculiarity with some shares being private and some public (though I have issues regardless of what type for deleting files) and I had no errors of this sort on 6.9.2. I also sometimes get errors and the inability to move files from certain paths to other locations via the apps (though no issues via windows or Krusader).

 

I'm pulling my hair out and will do whatever I can to provide information I can to support.

Edited January 11 by aqua

[ljm42]

Good news / bad news

 

The good news is that I can replicate this. I installed Total Commander on my Android phone and connected to a 6.11.1 server and got the strange error messages when deleting files.  It didn't matter whether the logged in user was the owner of the file or not, even with full perms the error showed and then inexplicably the file was deleted anyway.

 

Connecting the same app to Unraid 6.9.2 resulted in files being deleted without throwing any error messages.

 

And Windows is able to delete from either without any error messages.

 

 

The bad news is that this makes no sense to me. I've raised awareness of this internally and am open to ideas.