Guys, I'm at a loss here. I need help.

 

This morning I wrognfully used "New Permissions" and I messed up the permissions at "system" share. Now: I believe I only wrongfully changed the permissions in that share. I deselected appdata, but I might be wrong. (Yes, I now know about safe new perms).

 

Now obviously after I did that, when I edited a docker it didn't start. I got these kind of errors:

 

Quote

Execution error - Bad parameter

 

Also:

 

Quote

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. The command failed.

 

I've since tried to assign the correct owner to "system", but also to "system/docker/" and "system/libvirt". But I don't even know which owners and permission types they should have. I need help with this.

 

I also have backups of my dockers with the plugin Appdata Backup but I have two dockers that I don't know how will behave with this backup: Immich and NextCloud-AIO.

 

Should I retrieve a backup of appdata? Should I nuke docker? Should I change permissions? Recursively?

 

Also, I think this is important: I don't have a docker image but a directory.

 

Also number 2: Some dockers start but don't seem to be working fine: karakeep with karakeep-browserless and karapeep-meilisearch; seafile-12 and seafile-mariadb (I get an nginx error with this one).

 

Jellyfin doesn't start, with this error in the logs:

 

Quote

exec /jellyfin/jellyfin: permission denied

 

Nginx-Proxy-Manager gives this log (it does not say the time, though):

 

Quote

FROM
ChildProcess.<anonymous> (/app/lib/utils.js:23:35)
ChildProcess.emit (node:events:530:35)
ChildProcess._handle.onexit (node:internal/child_process:291:12)
onErrorNT (node:internal/child_process:483:16)
process.processTicksAndRejections (node:internal/process/task_queues:82:21)./run: line 21:   174 Trace/breakpoint trap   s6-setuidgid "$PUID:$PGID" bash -c "export HOME=$NPMHOME;node --abort_on_uncaught_exception --max_old_space_size=250 index.js"
s6-supervise backend: warning: unable to spawn ./run (waiting 60 seconds): Permission denied

 

2 minutes ago, naughtysnake said:

Also, I think this is important: I don't have a docker image but a directory.

You'll need to delete the directory and recreate it/reinstall your apps from Previous Apps. Wouldn't have been an issue with an image, but yeah with a directory it's wrecked. 

 

https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file

Edited April 12, 20251 yr by Kilrah

Thanks for your reply, Kilrah. I'll get to it soon enough.

 

Because I changed some permissions (maybe I shouldn't have done that), do I have to fix those changes by any chance?

 

For example: what are the correct permissions for system/libvirt? For system/docker? Does it matter?

35 minutes ago, naughtysnake said:

what are the correct permissions

What do you get from command line with this?

ls -lah /mnt/user/system

 

34 minutes ago, naughtysnake said:

I don't have a docker image but a directory

Why? Were you having problems filling docker.img? Making it larger or making it a folder won't fix that, it will only hide the problem.

 

The usual reason for filling docker.img is application(s) writing to paths that aren't mapped. Default 20G docker.img is often enough, maybe more depending on your dockers, but it shouldn't be growing, and making it large is almost certainly misconfiguration.

 

Makes me wonder if there aren't other things that could be improved about your configuration.

 

Just now, trurl said:

Makes me wonder if there aren't other things that could be improved about your configuration.

Attach Diagnostics ZIP to your NEXT post in this thread.

I changed to a folder many months ago. Yes, I was filling docker.img but there was nothing else that I could map outside of the .img (array or cache). Anyway, that is not related to my current problem. The problem is about permissions. I've deleted the docker folder as recommended. Would you recommend going back to an image? Would that affect the re-installation of dockers in any way?

 

I'm attaching the zip.

 

Recent moves: I've deleted the docker folder. I'll wait for instructions before re-creating it or re-creating an image. If you guys advice to go with an image, I'll do it but I'm worried I'll  also have to repair appdata or that this might affect my appdata backups. Crossing fingers!!

 

Edit:

 

This is a comment I've just found by an admin (link). I'm confused now 😅

 

Quote

btrfs-image vs xfs-image.  Dealer's choice.  No fundamental difference between the two

 

Image vs folder.  An image is say 20 Gig and always 20 Gig.  A folder is going to be say 1Gig, but as you install stuff will grow accordingly and if you uninstall will shrink accordingly.

 

IMO, the image is the antiquated method of handling docker on Unraid.  The real reason for the image being in existence is that in the 6.0 beta series (very early betas), the cache drive HAD to be formatted BTRFS if you wanted to run docker (and a folder was used).  Since many people didn't want to run btrfs on the cache drive, the image solution happened.

 

Nowadays, since the docker system supports the folder on btrfs, xfs, and zfs I don't see the point anymore in the image method anymore.

 

unraid-diagnostics-20250412-1542.zip

Edited April 12, 20251 yr by naughtysnake
Found something.

27 minutes ago, trurl said:

ls -lah /mnt/user/system

 

Sorry, I forgot this:

 

root@Unraid:~# ls -lah /mnt/user/system
total 0
drwxrwxrwx 1 nobody users   0 Apr 12 15:39 ./
drwxrwxrwx 1 nobody users 174 Apr 12 14:28 ../

 

 

Set permission manual to the share

cd /path to folder 

chown nobody:users -R *

chmod 777 -R *

Deleting the image and recreating my docker from the templates did it. I also re-created the appdata with Appdata Backup before deploying the various dockers. Thank you everyone. Fixed!

Edited April 12, 20251 yr by naughtysnake