Subject: bug#78638: 30.1; When editing a remote file owned by another user, Tramp signals an error because it cannot change the file mode

From: Eli Zaretskii <[email-masked]>
Date: Sun, 15 Jun 2025 11:16:35 +0300

> From: Michael Albinus <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Sun, 15 Jun 2025 09:41:09 +0200
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > Can you show a full recipe to reproduce it?
> 
> I've added a new user testuser1 on my Fedora machine, which uses the
> same group albinus as I do:
> 
> --8<---------------cut here---------------start------------->8---
> # sudo useradd -g albinus testuser1
> # id albinus
> uid=1000(albinus) gid=1000(albinus) groups=1000(albinus),4(adm),10(wheel),984(libvirt),1001(docker),1002(podman),1008(plugdev)
> # id testuser1
> uid=1007(testuser1) gid=1000(albinus) groups=1000(albinus)
> --8<---------------cut here---------------end--------------->8---
> 
> I've created a new file /tmp/xxx as user testuser1 with proper permissions
> 
> --8<---------------cut here---------------start------------->8---
> # sudo -u testuser1 touch /tmp/xxx
> # sudo chmod 660 /tmp/xxx
> # ll /tmp/xxx
> -rw-rw----. 1 testuser1 albinus 0 Jun 15 09:17 /tmp/xxx
> --8<---------------cut here---------------end--------------->8---
> 
> I've opened the file in Emacs (as user albinus), edited it, and tried to
> save:
> 
> --8<---------------cut here---------------start------------->8---
> # emacs -Q /tmp/xxx
> --8<---------------cut here---------------end--------------->8---
> 
> There is the error
> 
> --8<---------------cut here---------------start------------->8---
> basic-save-buffer-2: Opening output file: Permission denied, /tmp/xxx
> --8<---------------cut here---------------end--------------->8---

Thanks.  Can I ask you to show a Lisp backtrace from this error?

In any case, this is not about chmod, it's about opening the file, so
I'm not sure what Andreas said is the root cause here.

> Michael mentioned, that there was no problem on his local macOS
> machine. So I reran a similar test on a FreeBSD 14 VM, and indeed,
> there's no error.

We'd need to address this subtlety after we understand what happens on
Fedora.