On 2022-04-17 at 18:16, Greg Wooledge wrote: > On Sun, Apr 17, 2022 at 03:44:33PM -0400, The Wanderer wrote: [that in an earlier message, Greg Wooledge wrote:] >>> (You've also forgotten the sticky bit on your mounted >>> directory.) >> >> While that's certainly not ideal, I can't see how it could cause >> the exhibited behavior in this case; from what I can find reading >> up on the sticky bit to refresh my memory, having it unset should >> just result in being able to do *more* things with/inside the >> directory than would be the case if it were set. > > Well, some applications may check the permissions on the directory, > see that they are set wrong, and refuse to operate. I have no idea > whether their VNC server is one of them, but there's certainly > precedent. Given the error messages being displayed, I don't think it likely that this is the result of a failed permissions check; it looks as if the program called mkdir() on the specified path, and is just dealing with the error code returned by that function call. I initially thought this was the C library's mkdir() (see 'man 2 mkdir') - but since that appears to require a second argument to specify the mode, and there's only one argument presented here, I'm not so sure of that anymore. This might even be some higher-level language that's layered over top of the C mkdir(), which would make it even messier to try to understand. > But as soon as I saw they had made a symlink from a standard > location to a nonstandard location, I *immediately* thought of > AppArmor, because that has been an issue so many times in the past > with so many apps. I would be surprised if the WSL2 version of Debian was using AppArmor enabled by default, but I suppose it's hard to rule anything out, especially when it comes to Microsoft. > I don't know precisely why the EAGAIN errno is happening, but it > isn't EACCES so it's not a direct refusal by file system permissions, > and it's not EPERM so it's not a direct refusal for not being > superuser. It's also not ENOSPC (disk full), so I don't think it's > due to a full file system, but it doesn't take much effort to check > that, so I would check anyway. Assuming this *is coming from the mkdir() C library function, it gets weirder. On my own (non-WSL-based) Debian system, the man page does not list EAGAIN for that function. (I'll note that multiple man pages say that errno 11 may legally be, and/or specifically is, used for both EAGAIN and EWOULDBLOCK. I can't see why the latter would make any more sense here than the former, though.) I think this almost has to be a WSL2-specific detail - probably something about how it layers *nix semantics over top of filesystems which are not compatible with those semantics. (I think it does at least part of it via having actual virtual-hard-disk files, but that can't be everything, and in this specific case it's pointing to a mounted filesystem which is very probably on the host machine and therefore not in such a contained filesystem.) From what I gather, WSLg is explicitly in an experimental / pre-release sort of mode, so it's not surprising that there'd be incompatibilities and other bugs. I rather think the OP has just hit one of those bugs: a case where some existing *nix applications are doing things that are legitimate in their original environment but don't (currently) work under WSLg, or in other words, a case where WSLg isn't sufficiently compatible yet. It might even be worth filing a report about this on the WSLg GitHub issue tracker; they might decide to declare it not their problem and close the issue, but they might also consider it legitimate and track it down and try to get this working. (If the solution winds up involving not using that symlink, though, I think - based on what I've seen from existing issue discussions - that that's going to be a nonstarter.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature