Hi, Quoting Johannes Schauer Marin Rodrigues (2024-01-13 20:18:34) > Quoting Helmut Grohne (2024-01-12 21:58:00) > > > What can cause mkfs.ext4 to fail with a "Permission denied" error? > > I think this is our typical problem when dealing with user namespaces. I > > guess that the thing that fails here is mkfs.ext4 opening the target image > > file (to be formatted). That file has earlier been chowned to the root uid > > inside the namespace, so permission should be there, but you need more. You > > also need execute permission (to the first uid of your namespace) for the > > containing directory up until the root. I guess that none of those are > > world-executable and not by chanced owned by your first subuid nor owned by > > the first group in your subgid range. > > I'm not yet convinced that this is it. The problem occurs for Francesco when > using either /tmp or /dev/shm as a temporary directly. By default, those two > locations should have the desired permission bits set. Lets check whether > world-execute permissions are set for all directories up until root. I have > this: > > $ stat -c "%a %n" / /dev /dev/shm /tmp > 755 / > 755 /dev > 1777 /dev/shm > 1777 /tmp > > Francesco, what are the world execute permissions on all path components up > to /tmp and /devv/shm in your case?
scratch what I said in your last mail. Your problem is with the creation of the
image and not with the temporary chroot directory. What Helmut said is likely
correct and exactly the problem you are facing. To verify, you could run the
command you posted initially inside your $HOME directory and show us the
permission bits of your $HOME. Mine are these:
stat -c "%a %n" $HOME
711 /home/josch
I assume in your case, you have a 0 at the end of the octal permissions?
Thanks!
cheers, josch
signature.asc
Description: signature
