I was noticing that my qbittorrent, even when i selected "remove file" was not deleting files on my drive so i ran "New permission" by accident on 10/12/24 instead of "Docker Safe New Perms", and now my entire Unraid docker system is completely broken (i.e. apps not working).

 

I thought i may have a CA backup to restore to but it's unfortunately from 1/10/24 of which i've made massive changes to all my various apps since then which i think will cause issues in terms of a restore and i don't want to go down that restore path of such an old backup. I had thought my CA backup was running on a regular schedule but apparently not

 

I turned off docker in settings and then ran

chmod -R 777 /mnt/user/appdata/

but that doesn't seem to fix anything, i still get "bad parameter" with no apps working.

 

does anyone have any advice on how i can restore my apps to their previous working state? I'm most concerned about plex, emby, sonarr, radarr, lidarr, qbittorrent, tautulli in terms of having all my appdata restored from it's most recent operating state before i messed up with "new permissions".

 

 

so based on @HalianElf  and @gacpac immense help on the discord channel, i was able to get my apps working again after every single container stopped working with the bad parameters error.

 

First - i had run chmod -R 777 /mnt/user/appdata/ command after the docker was stopped, and it didn't do anything (same bad parameter error). HalianElf asked if i am able to make any changes to the docker template, to which it spit out an error "docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/init": permission denied: unknown."

 

So we troubleshooted by deleting the docker image so that docker could rebuild again (it's a very large folder in /mnt/user/system/ though i actually just renamed the docker folder as docker.old instead of ticking the delete checkbox inside settings -> docker). I then navigated to the docker tab in main unraid GUI and manually added each container again which populated with all my existing templates (apparently you can go to apps -> previous apps -> docker and select all the apps at once to reinstall instead of having to go one by one). Note - each container re-populated into its respective FolderView (fka Docker Folders plugin) section. The only thing that seems to have not traveled was the auto-start information which i had to re-enable so that certain containers spin-up automatically after launch. 

 

For now - it looks like my plex, emby, -arrs, qbit/rtorrent, tautulli are working as far as the eye can tell. I think the "chmod -R 777" may have been an unnecessary step i pre-emptively ran before fixing docker folder itself. I am not too sure if i have done some potential future damage running that 777 permission command over /appdata/, i'm hoping my unraid doesn't break in a future restart/update to latest version.

 

If anyone thinks i have done some damage with this 777 permission setting, I'm all ears for how to fix that part. I supposed i could:

1. Turn off docker
2. Backup my existing working "mnt/user/system/docker" and "mnt/user/appdata" (so i can restore if it something breaks again)
3. Run tools -> new permissions -> on /appdata/ (which will presumably break docker again)
4. Again delete /mnt/user/system/docker/ and re-build the docker containres via existing templates in apps -> previous apps
5. Now my /appdata/ should have the default 99:100 permissions (instead of 777 currently?) and docker hopefully works again 

 

Note - this person here also seemed to implement the same fix too on reddit.

Edited October 13, 2024Oct 13 by Linguafoeda

 

On 10/14/2024 at 12:17 AM, Linguafoeda said:

so based on @HalianElf  and @gacpac immense help on the discord channel, i was able to get my apps working again after every single container stopped working with the bad parameters error.

 

First - i had run chmod -R 777 /mnt/user/appdata/ command after the docker was stopped, and it didn't do anything (same bad parameter error). HalianElf asked if i am able to make any changes to the docker template, to which it spit out an error "docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/init": permission denied: unknown."

 

So we troubleshooted by deleting the docker image so that docker could rebuild again (it's a very large folder in /mnt/user/system/ though i actually just renamed the docker folder as docker.old instead of ticking the delete checkbox inside settings -> docker). I then navigated to the docker tab in main unraid GUI and manually added each container again which populated with all my existing templates (apparently you can go to apps -> previous apps -> docker and select all the apps at once to reinstall instead of having to go one by one). Note - each container re-populated into its respective FolderView (fka Docker Folders plugin) section. The only thing that seems to have not traveled was the auto-start information which i had to re-enable so that certain containers spin-up automatically after launch. 

 

For now - it looks like my plex, emby, -arrs, qbit/rtorrent, tautulli are working as far as the eye can tell. I think the "chmod -R 777" may have been an unnecessary step i pre-emptively ran before fixing docker folder itself. I am not too sure if i have done some potential future damage running that 777 permission command over /appdata/, i'm hoping my unraid doesn't break in a future restart/update to latest version.

 

If anyone thinks i have done some damage with this 777 permission setting, I'm all ears for how to fix that part. I supposed i could:

1. Turn off docker
2. Backup my existing working "mnt/user/system/docker" and "mnt/user/appdata" (so i can restore if it something breaks again)
3. Run tools -> new permissions -> on /appdata/ (which will presumably break docker again)
4. Again delete /mnt/user/system/docker/ and re-build the docker containres via existing templates in apps -> previous apps
5. Now my /appdata/ should have the default 99:100 permissions (instead of 777 currently?) and docker hopefully works again 

 

Note - this person here also seemed to implement the same fix too on reddit.

 

Hi!

So, I just did the same mistake as you and I'm currently waiting on a parity check due to an unclean shutdown.

I haven't done anything yet.

Hoping that my situation is identical to yours, could you confirm the following steps:

 

1. I have a docker folder, not image. Do I backup /mnt/user/docker or /mnt/user/system/docker? Or both?

2. Which one of the previously mentioned folders should I be deleting?

3. Go into previous apps and reinstall the containers.

4. Hope it works?

 

If this is "the fix", this means that only the perms changed in the docker files are the ones affecting them, right? The appdata itself and its permissions are irrelevant.

 

Thanks for your time.

For anyone else that comes across this post. I tried what @Linguafoeda described above but it wasn't working for me. Dockers said they were running but I couldn't open them and their logs were filled with permission denied errors.

1. I stopped the docker service.
2. Copied the docker and appdata folder to another location. Not necessarily needed, but just in case. (for me they were located in /mnt/user/appdata and /appdata/docker)

3.  Opened the web terminal and ran:

    newperms /mnt/user/appdata

   Which runs:

   chmod -R u-x,go-rwx,go+u,ugo+X /mnt/user/appdata
   chown -R nobody:users /mnt/user/appdata
   chmod -R 777 /mnt/user/appdata

   As you can see, it runs the 'chmod -R 777' command, which I ran earlier, like the OP did, and the dockers were still having issues. Maybe, for my instance, the other permission commands needed to run first. I don't really know. (Found this command in the reddit post provided in the OP's note)

4. Started the docker service.

5. Reinstalled the dockers via apps->previous apps

Everything came back up like nothing happened.

 

I do backup my appdata folder frequently and doing a restore didn't fix the issue either. The issue is with the permissions for the appdata folder itself and the backup process either doesn't backup permissions or backs up the docker folders inside the appdata folder (so appdata permissions wouldn't get backed up anyway). Thanks @Linguafoeda for discovering this info. Just wanted to add another potential solution to your post.

Edited April 9Apr 9 by dexdiman