Hi,

I'm just getting to grips with Unraid and Linux and I was having problems where folders deleted from a Windows 10 VM on the share weren't being deleted, (they would still appear but with an access denied error). Deleting with mc worked fine.

Stupidly, I ran the "New Permissions" command - this was based on some old advice on this forum. As docker apps no longer reside in a single image file, it proceded to remove all execute permissions from all of the files. This proceeded to kill every docker app I had loaded.

Why is there a button to basically kill your apps still available on Unraid? I realise there is a note at the end that says it "may" affect docker, but I'm sure I'm not the only one that has basically caused their server to commit suicide?

The tool is very useful for many situations. Misuse of the tool has been a problem since the addition of Dockers and VM's. BUT at the same time, they are also the cause of permissions problems in many cases. They are setup wrong to begin with (Usually Dockers) or are configured wrong by the Unraid user (VM's).

The tool was intended to be used on Shares that are normally shared to Array users. (Basically those accessed via SMB and NFS) This does not include the appdata domains system and isos shares if they exist. (These are used by Dockers containers and VM's for their own purposes are not intended to be accessed via normal share access.

41 minutes ago, AndyS said:

Stupidly, I ran the "New Permissions" command - this was based on some old advice on this forum. As docker apps no longer reside in a single image file, it proceded to remove all execute permissions from all of the files. This proceeded to kill every docker app I had loaded.

Why is there a button to basically kill your apps still available on Unraid? I realise there is a note at the end that says it "may" affect docker, but I'm sure I'm not the only one that has basically caused their server to commit suicide?

The problem is that New Permissions does not always kill Docker applications. It only does that to Docker containers that require different permissions from the standard Unraid ones. So "may" is the proper term! I don't know what you thought was the reason that you needed to run it on appdata if you had a Window VM permission problem...

Over the years, Unraid has changes. When this tool was first added (When Unraid moved from version 4.X to 5.0 when every owner, group was root/root which was a real security issue since any one with share access also had root privileges! (My gut feeling is if Docker and VM's had not been added in version 6, this tool would now be completely unnecessary as both of these have the capability to screw up the permissions for normal SMB and NFS share access! )

What should be done for a permission issue to find out what the problem is. Is it an owner/group issue or a file permission issue and what portion of the file system is affected. Basically you have to go down to the command line level and look at these properties. Once you find the problem, you can decide if the New Permissions tool will fix it and run it only on that portion(s) of the file system. You also have to correct the settings which caused the problem in the first place!

About the tool. Here is the screen, what changes would you suggest to the wording?

This section of the tool tells you what settings have to be to work.

There should be no read-only files in user Shares today and I have no idea why that carried over. (One piece of minor information, SMB will often set the 'x' bit for 'owner'. This is relativity harmless in the greater scheme of things except to the Linux purist.)

Thanks for your detailed response. You are correct, this is entirely my fault for running this on my cache drive and not on the downloads share - which would have helped. I suppose I'm more used to a UI holding your hand a little more, if it saw that you were going to run this on the appdata or system folder, maybe another warning would be useful? Maybe default to Shares as the first option - not Disks?

The unfortunate fallout from this is that I've had to set all files in appdata and system to +x. I hope that this doesn't have a knock on problem. I'm tempted to destroy the docker folder and start again - if it wasn't for the rebuild of plex and sonarr.

Thanks for the help though.

2 minutes ago, AndyS said:

I suppose I'm more used to a UI holding your hand a little more, if it saw that you were going to run this on the appdata or system folder, maybe another warning would be useful? Maybe default to Shares as the first option - not Disks?

I agree with you on this one. Since you are the one who had a problem (squeaky wheel), I would suggest that you make a 'Feature Request' (about four subforums below this 'General Support' one) and ask that this be done and point back to this thread. And while you are about it, Under the 'Share' setting, suggest getting rid of the 'All' option!