Scribbles for my memory

I wanted a second local account to read /home/davidw. The user was already in group davidw, and ls looked like it should just work:

$ ls -ld /home/davidw
drwxrwx---+ 272 davidw davidw 16384 Aug 19 16:56 /home/davidw

Group davidw has rwx, right there in the middle. Except every access failed:

$ sudo -u desk ls /home/davidw
ls: cannot open directory '/home/davidw': Permission denied

The + at the end of the mode string is the tell. Once a file has a POSIX ACL, the middle triad printed by ls stops being the group permission and becomes the ACL mask — a ceiling on what every named user, named group, and the owning group may get. The real group entry is only visible via getfacl:

$ getfacl -p /home/davidw
user::rwx
user:libvirt-qemu:--x
group::---          <-- the actual group permission: nothing
mask::rwx           <-- this is what ls printed as "rwx"
other::---

So the directory was 700 all along. Someone (libvirt, in my case) added user:libvirt-qemu:--x at some point, and adding any named entry forces a mask into existence — set wide enough to cover that entry. ls dutifully displayed the mask, and it looked exactly like group access.

The mask cuts both ways: it can also revoke access that getfacl seems to grant. An entry of user:desk:rwx under mask::r-x yields read-only — getfacl marks it for you:

user:desk:rwx                   #effective:r-x

Two consequences worth internalizing. First, on any path with a +, getfacl is the only source of truth; don't reason from ls. Second, chmod g+rx on an ACL'd file doesn't set the group permission — it sets the mask, which is almost never what you meant. Grant access with a named entry instead, which is narrower and trivially reversible:

sudo setfacl -m u:desk:rwx /home/davidw   # grant
sudo setfacl -x u:desk     /home/davidw   # revert

One unrelated snag if you're doing this to share a checkout: git will refuse the now-reachable repos with detected dubious ownership in repository, because they're owned by a different uid. Fix it per-user, not with sudo:

sudo -u desk git config --global --add safe.directory '*'

Git Bash and MSYS2 can load different Git executables while sharing the same ~/.gitconfig. http.sslbackend=schannel works with Git for Windows, but an MSYS2-native Git may support only OpenSSL and fail with Unsupported SSL backend.

Remove the MSYS2 Git package and put Git for Windows first in MSYS2's PATH:

pacman -R --noconfirm git
printf '%s\n' 'export PATH="/c/Program Files/Git/cmd:$PATH"' >> ~/.bashrc
source ~/.bashrc
hash -r

Use one shared configuration:

git config --global http.sslbackend schannel
git config --global credential.helper manager

Verify both shells resolve the same executable:

type -a git
git --version
git ls-remote origin HEAD

This keeps certificate verification in the Windows certificate store and avoids shell-specific OpenSSL CA or stale credential-store differences. Do not disable TLS verification with http.sslVerify=false.

Log in at the physical console, then RDP in as the same user, and you get a black screen. Worse, unlike Windows, the remote connection can't kick the console session — so any machine you walked away from while logged in is a machine you can't reach.

Neither is really an RDP problem, and one trick fixes both: create a second Unix account that owns the console.

sudo adduser desk

desk logs in at the display manager and holds the physical machine. Your real user never logs in locally at all — its desktop exists only as an xrdp session. When you're sitting at the machine, desk connects to it over loopback:

xfreerdp3 /v:127.0.0.1 /u:youruser +clipboard /multimon

Now every client is equal. Connect from a laptop on the other side of the world and it takes over the same session your local xfreerdp was showing; the local one just exits and desk's desktop is still sitting there underneath. Don't wrap that command in an auto-reconnect loop, or the machine at home will keep stealing the session back and you'll never get in from outside.

The black screen was never about RDP — it was one user running two concurrent desktop sessions, colliding on all the per-user singletons: the session D-Bus, xfce4-session, ibus, gvfs. The second session's window manager never comes up. Two different uids have none of that.

The takeover failure is a separate mechanism. "Taking over" is really xrdp-sesman reconnecting you to a session in its own table. A console session started by lightdm was never in that table, so nothing can ever reattach to it — which is also why a second RDP client can kick the first: those two are the same session.

Git Bash doesn't ship tmux. A standalone MSYS2 install does — but out of the box it ignores your Windows $HOME, doesn't inherit the Windows PATH, and if you wire it into Windows Terminal, silently ignores the config you think is fixing it.

Two settings make MSYS2 match Git Bash:

HOME — edit C:\msys64\etc\nsswitch.conf:

db_home: env windows cygwin desc
db_shell: env windows cygwin desc
db_gecos: env windows cygwin desc

Default MSYS2 uses cygwin desc, which invents a separate /home/<user> instead of your real Windows profile. This is the exact line Git for Windows ships with, so it makes MSYS2 pick up C:\Users\<you> — same .bashrc, .gitconfig, .ssh as Git Bash, no copying needed.

PATH — MSYS2 doesn't inherit the Windows PATH by default, so anything installed via scoop/chocolatey/etc. won't resolve. Set MSYS2_PATH_TYPE=inherit in the relevant launcher .ini (mingw64.ini, ucrt64.ini, next to the exe in C:\msys64).

The gotcha: if you launch MSYS2 through Windows Terminal with the commonly documented

msys2_shell.cmd -defterm -here -no-start -ucrt64

the .ini file is never read. Only the GUI launchers (mingw64.exe, ucrt64.exe) read it — msys2_shell.cmd has its own separate flag:

msys2_shell.cmd -defterm -here -no-start -ucrt64 -use-full-path

Add -use-full-path straight to the Windows Terminal profile's commandline. Or, for a fix that works no matter how MSYS2 gets launched (Windows Terminal, VS Code, a script), set it once at the system level from an elevated shell:

[Environment]::SetEnvironmentVariable('MSYS2_PATH_TYPE', 'inherit', 'Machine')

Restart the terminal for it to take effect. Then pacman -S tmux, and you've got tmux running in an environment that otherwise looks and feels exactly like Git Bash.

mktemp -d on Windows Git Bash returns a path like C:\Users\you\AppData\Local\Temp\2/tmp.XXX. The 2 after Temp\ is not a separator — GNU tar reads it as the start of an octal escape (\2 → \002), so any tar -C <that-path> silently rewrites the destination to a non-existent path and the extract aborts with Cannot open: No such file or directory.

The fix is to stop passing the bad path as an argument at all:

# Wrong — passes $dst as -C argument, tar mangles the backslashes
tar -xf archive.tar.gz -C "${dst}"

# Right — cd into it first, reference files by basename
( cd "${dst}" && tar -xf archive.tar.gz )

This is the same shape as --force-local, the other GNU-tar-on-Windows gotcha: GNU tar sees the leading C: of a Windows path and reads it as host:spec for a remote archive. --force-local only fixes the second one; only cd-ing into the destination fixes the first.