Unknowingly ran wrong 'Fix Permission' Tool / Appdata is a Permissions Mess, please help!

[stry8993]

Hey folks, I know this has been mentioned in other variations, but I can't seem to find/pin down a solution to what I did. I was following a tutorial after adding some really crappy, slow drives to unraid to get more space, but, then finding out the hard way it slowed EVERYTHING down. So I followed a guide to help remove those drives as safely as possible. Problem is, that guide predated the docker safe permissions/fix common problems, so I ran the Fix Permissions in Tools but unchecked the drive where I had assumed/hoped/guessed my appdata was stored (as thats where I'd set it to be) by the looks of it, and I totally messed up the permissions on my docker containers/appdata folder. I've got some of them working, most of the functionality is there (though any issues I'm not really alerted to just yet, but I'm sure they'll crop up).

 

How I found out there was an issue, is that anything in Plex that was trying to use the EasyAudioEncoder Codec would just constantly buffer or boot the viewer (myself included, so locally and remote). EAC3 5.1 is fine though... but another issue, is in the transcoding, where it would see my GPU  in the drop down, now its just auto, but it IS using it. Using nvidia-smi I can see the plex process, and it does seem to be transcoding for people.

 

But I'm worried that these things point to a much wider issue, I tried to exclude the drive where my appdata folder sits, but I don't think it mattered too it, in Fix Permissions, which drives I picked, because it definitely got too it.

 

I spent much of this morning trying to fix SWAG/DockerSocket/Overseerr and did manage to get it going again, but, yeah... I could really use a get out of jail card here from people who have way more experience and knowledge than I do.

 

 

 

EDIT: If I need to delete the appdata and docker containers folder and start over, that is mostly okay, it'll just take some time. If thats the better more thorough alternative, please let me know, and if there is any guidance on how to properly do that (make sure its nuked, cleaned, so that when I redo it theres no issues that crop up) then please let me know.

Edited December 3, 2023 by stry8993

[itimpi]

Each docker container can have its own requirements around any folders/files that are part of its working set located in a folder under the appdata share so the only foolproof way to fix it is to remove the relevant folder in appdata for a particular docker container and let it be recreated from scratch.  Any mappings to other shares should be OK.   You can do this for just those docker containers that have problems if you can identify them.

 

You can delete the folder using the Dynamix File Manager plugin with the relevant docker container stopped and then restart the container to get the folder recreated.   If there are any containers where you really do not want to loose the current working set data then you would have to ask for guidance on that particular container in its support thread.

[stry8993]

20 minutes ago, itimpi said:

Each docker container can have its own requirements around any folders/files that are part of its working set located in a folder under the appdata share so the only foolproof way to fix it is to remove the relevant folder in appdata for a particular docker container and let it be recreated from scratch.  Any mappings to other shares should be OK.   You can do this for just those docker containers that have problems if you can identify them.

 

You can delete the folder using the Dynamix File Manager plugin with the relevant docker container stopped and then restart the container to get the folder recreated.   If there are any containers where you really do not want to loose the current working set data then you would have to ask for guidance on that particular container in its support thread.

 

kk, I'll give that a shot. Thank you so much!