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

Previous Next

To reply to this bug, email your comments to 78638 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael McClennen <mmcclenn <at> geology.wisc.edu>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 30.1; When editing a remote file owned by another user, Tramp signals
 an error because it cannot change the file mode
Date: Thu, 29 May 2025 21:09:31 +0000

Current behavior of Emacs
-------------------------

1. Use Tramp to edit any remote file owned by a different user, where the
   file mode allows you to write to it.

2. Make a change to the file, and then save it.

3. The changes are saved, but the following error is thrown:
   "Error while changing file’s mode /scp:[hostname]:[filename]"

4. Make another change to the file, and save it again.

5. Emacs asks "[filename] has changed since it was last visited or
   saved. Save anyway?". This message is incorrect, since the file
   contents have not changed and were in fact saved correctly. Presumably, this
   question is triggered because the file mode is different than expected,
   but this particular case should not trigger this question.

Expected behavior
-----------------

1. Use Tramp to edit any remote file owned by a different user, where
   the file mode allows you to write to it.

2. Make a change to the file, and then save it.

3. The changes should be saved, and no error should be thrown. Perhaps
   the Tramp code could check whether the owner is different, and ignore
   the file mode if that is the case.

4. Make another change to the file, and save it again.

5. The save should occur without any questions, provided that the contents of
   the file have not changed on the remote server since the file was last
   visited or saved.

Why this is important
---------------------

When editing collaboratively with a remote partner, it is important that
Emacs should tell me truthfully whether or not my partner has changed
the file before I save it. If Tramp always flags a file owned by my
partner as having been changed since I saved it, I have no way to know
whether that is actually true or not.


In GNU Emacs 30.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
 Version 10.14.6 (Build 18G9323)) of 2025-02-24 built on
 builder10-14.lan
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.7.1

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules 'CFLAGS=-DFD_SETSIZE=10000
 -DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'

Configured features:
ACL GLIB GMP GNUTLS JPEG LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/michaelm/.emacs.d/elpa/eglot-1.18/eglot hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/eglot

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epa derived
epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
jka-compr cl-print debug backtrace find-func perl-mode grep compile
novice cl-extra noutline outline ispell tabify face-remap cus-edit pp
cus-start help-fns radix-tree yank-media mhtml-mode css-mode smie eww
url-queue thingatpt shr pixel-fill kinsoku url-file svg xml puny mm-url
gnus nnheader gnus-util text-property-search mail-utils range wid-edit
mm-util mail-prsvr color sgml-mode dom misearch multi-isearch vc-hg
vc-git diff-mode track-changes easy-mmode vc-bzr vc-dispatcher js
c-ts-common treesit imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs tramp-cmds tramp-cache
time-stamp tramp-sh tramp trampver tramp-integration files-x
tramp-message help-mode tramp-compat xdg shell pcomplete comint ansi-osc
ring parse-time iso8601 time-date format-spec ansi-color tramp-loaddefs
dired-aux dired dired-loaddefs cperl-mode rx facemenu elec-pair delsel
cus-load info eglot-autoloads eldoc-diffstat-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 365713 99102) (symbols 48 19681 0) (strings 32 74564 3835)
 (string-bytes 1 2064538) (vectors 16 39135)
 (vector-slots 8 1144840 191291) (floats 8 256 544)
 (intervals 56 61413 464) (buffers 992 36))

Message #8 received at 78638 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael McClennen <mmcclenn <at> geology.wisc.edu>
Cc: 78638 <at> debbugs.gnu.org
Subject: Re: bug#78638: 30.1;
 When editing a remote file owned by another user, Tramp signals an
 error because it cannot change the file mode
Date: Fri, 30 May 2025 10:34:00 +0300

> Date: Thu, 29 May 2025 21:09:31 +0000
> From:  Michael McClennen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> Current behavior of Emacs
> -------------------------
> 
> 1. Use Tramp to edit any remote file owned by a different user, where the
>    file mode allows you to write to it.
> 
> 2. Make a change to the file, and then save it.
> 
> 3. The changes are saved, but the following error is thrown:
>    "Error while changing file’s mode /scp:[hostname]:[filename]"
> 
> 4. Make another change to the file, and save it again.
> 
> 5. Emacs asks "[filename] has changed since it was last visited or
>    saved. Save anyway?". This message is incorrect, since the file
>    contents have not changed and were in fact saved correctly. Presumably, this
>    question is triggered because the file mode is different than expected,
>    but this particular case should not trigger this question.
> 
> Expected behavior
> -----------------
> 
> 1. Use Tramp to edit any remote file owned by a different user, where
>    the file mode allows you to write to it.
> 
> 2. Make a change to the file, and then save it.
> 
> 3. The changes should be saved, and no error should be thrown. Perhaps
>    the Tramp code could check whether the owner is different, and ignore
>    the file mode if that is the case.
> 
> 4. Make another change to the file, and save it again.
> 
> 5. The save should occur without any questions, provided that the contents of
>    the file have not changed on the remote server since the file was last
>    visited or saved.
> 
> Why this is important
> ---------------------
> 
> When editing collaboratively with a remote partner, it is important that
> Emacs should tell me truthfully whether or not my partner has changed
> the file before I save it. If Tramp always flags a file owned by my
> partner as having been changed since I saved it, I have no way to know
> whether that is actually true or not.

Please read the node "Backup Copying" in the Emacs user manual.  I
think Emacs behaves as expected in this case, because the default
method of saving a file also makes you the owner of the file, and that
is not always allowed when you edit files owned by a different user
(presumably in a directory owned by that user).  What you need in
these cases is to set either backup-by-copying to t or
backup-by-copying-when-mismatch to nil (and perhaps increase
backup-by-copying-when-privileged-mismatch to a very large number), so
that backup files are created by copying and not by renaming.

Message #11 received at 78638 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael McClennen <mmcclenn <at> geology.wisc.edu>
Cc: 78638 <at> debbugs.gnu.org
Subject: Re: bug#78638: 30.1; When editing a remote file owned by another
 user, Tramp signals an error because it cannot change the file mode
Date: Sat, 31 May 2025 09:54:42 +0300

[Please use Reply All to reply, to keep the bug tracker CC'ed.]

> From: Michael McClennen <mmcclenn <at> geology.wisc.edu>
> Date: Fri, 30 May 2025 19:08:09 +0000
> 
> Unfortunately, Emacs is not behaving as expected. My emacs currently has backup-by-copying = nil,
> backup-by-copying-when-linked = nil, and backup-by-copying-when-mismatch = t. That ought to result in
> copying being used in this situation, which should not cause the problem I am experiencing. 

Not necessarily.  What you describe are the default values.  They
result in copying being used only if the file-owner's user ID and
group ID do not exceed the value of
backup-by-copying-when-privileged-mismatch, which is 200 by default.
So this only uses copying by default for files owned by root and other
super-user accounts, which I'm guessing is not your case.

> I just tested this by creating a file on my local machine, changing its ownership to a different user, and then
> editing it. The file saves just fine, with no errors. The owner remains as I originally set it. Emacs also
> correctly tells me that the file has not changed since I last saved it. I tried this with various file modes, and it
> did not throw any “error setting the file mode”.
> 
> The problem is only occurring with Tramp. When I edit a remote file owned by somebody else and then save
> it, the ownership doesn’t change. As far as I am aware, that means it is using copying. But I still get the
> errors that I described in my bug report. I don’t think it is too much to ask that editing a remote file with
> Tramp should exhibit as closely as possible the same behavior as editing a local file, and in particular that it
> shouldn’t (a) throw unnecessary errors, and (b) get confused about whether or not the file has changed
> since it was last saved.

Did you try setting backup-by-copying = t ?  If not, could you please
try it and see if the problem with editing via Tramp goes away then?
This experiment should tell us whether the problem is with Tramp and
only with Tramp.  Because the alternative is that your remote files
and directories have some as yet unknown file ownership and access
issues which the Emacs core functionality doesn't handle correctly.
(The experiment with local files you did might not reproduce
accurately the exact conditions with the original remote files.)  IOW,
we need to know whether to look for the reasons in Tramp or in Emacs
core.

Thanks.

Message #14 received at 78638 <at> debbugs.gnu.org (full text, mbox):

From: Michael McClennen <mmcclenn <at> geology.wisc.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "78638 <at> debbugs.gnu.org" <78638 <at> debbugs.gnu.org>
Subject: Re: bug#78638: 30.1; When editing a remote file owned by another
 user, Tramp signals an error because it cannot change the file mode
Date: Sat, 31 May 2025 20:12:07 +0000

I set the value of ‘backup-by-copying-when-privileged-mismatched’ to 10000, and the error still occurs. I then set ‘backup-by-copying’ to t, and the error still occurs. I checked the *Messages* buffer, and it reports that Emacs is using copying for this file. This is definitely an error in Tramp, not the result of proper Emacs behavior.

  — Michael McClennen

> On May 31, 2025, at 1:54 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> [Please use Reply All to reply, to keep the bug tracker CC'ed.]
> 
>> From: Michael McClennen <mmcclenn <at> geology.wisc.edu>
>> Date: Fri, 30 May 2025 19:08:09 +0000
>> 
>> Unfortunately, Emacs is not behaving as expected. My emacs currently has backup-by-copying = nil,
>> backup-by-copying-when-linked = nil, and backup-by-copying-when-mismatch = t. That ought to result in
>> copying being used in this situation, which should not cause the problem I am experiencing. 
> 
> Not necessarily.  What you describe are the default values.  They
> result in copying being used only if the file-owner's user ID and
> group ID do not exceed the value of
> backup-by-copying-when-privileged-mismatch, which is 200 by default.
> So this only uses copying by default for files owned by root and other
> super-user accounts, which I'm guessing is not your case.
> 
>> I just tested this by creating a file on my local machine, changing its ownership to a different user, and then
>> editing it. The file saves just fine, with no errors. The owner remains as I originally set it. Emacs also
>> correctly tells me that the file has not changed since I last saved it. I tried this with various file modes, and it
>> did not throw any “error setting the file mode”.
>> 
>> The problem is only occurring with Tramp. When I edit a remote file owned by somebody else and then save
>> it, the ownership doesn’t change. As far as I am aware, that means it is using copying. But I still get the
>> errors that I described in my bug report. I don’t think it is too much to ask that editing a remote file with
>> Tramp should exhibit as closely as possible the same behavior as editing a local file, and in particular that it
>> shouldn’t (a) throw unnecessary errors, and (b) get confused about whether or not the file has changed
>> since it was last saved.
> 
> Did you try setting backup-by-copying = t ?  If not, could you please
> try it and see if the problem with editing via Tramp goes away then?
> This experiment should tell us whether the problem is with Tramp and
> only with Tramp.  Because the alternative is that your remote files
> and directories have some as yet unknown file ownership and access
> issues which the Emacs core functionality doesn't handle correctly.
> (The experiment with local files you did might not reproduce
> accurately the exact conditions with the original remote files.)  IOW,
> we need to know whether to look for the reasons in Tramp or in Emacs
> core.
> 
> Thanks.

Message #17 received at 78638 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael McClennen <mmcclenn <at> geology.wisc.edu>,
 Michael Albinus <michael.albinus <at> gmx.de>
Cc: 78638 <at> debbugs.gnu.org
Subject: Re: bug#78638: 30.1; When editing a remote file owned by another
 user, Tramp signals an error because it cannot change the file mode
Date: Sun, 01 Jun 2025 08:19:45 +0300

> From: Michael McClennen <mmcclenn <at> geology.wisc.edu>
> CC: "78638 <at> debbugs.gnu.org" <78638 <at> debbugs.gnu.org>
> Date: Sat, 31 May 2025 20:12:07 +0000
> 
> I set the value of ‘backup-by-copying-when-privileged-mismatched’ to 10000, and the error still occurs. I then set ‘backup-by-copying’ to t, and the error still occurs. I checked the *Messages* buffer, and it reports that Emacs is using copying for this file. This is definitely an error in Tramp, not the result of proper Emacs behavior.

Thanks, I agree with your conclusion.

Michael, could you please look into this?

Message #20 received at 78638 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Michael McClennen <mmcclenn <at> geology.wisc.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78638 <at> debbugs.gnu.org
Subject: Re: bug#78638: 30.1; When editing a remote file owned by another
 user, Tramp signals an error because it cannot change the file mode
Date: Sun, 01 Jun 2025 18:42:16 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi,

>> I set the value of ‘backup-by-copying-when-privileged-mismatched’ to
>> 10000, and the error still occurs. I then set ‘backup-by-copying’ to
>> t, and the error still occurs. I checked the *Messages* buffer, and
>> it reports that Emacs is using copying for this file. This is
>> definitely an error in Tramp, not the result of proper Emacs
>> behavior.
>
> Thanks, I agree with your conclusion.
>
> Michael, could you please look into this?

Will do.

Michael: as a first step, I'd like to gather more information. Michael,
could you pls start a new Emacs session like this:

--8<---------------cut here---------------start------------->8---
# emacs -Q -l tramp --eval '(setq tramp-verbose 6 backup-by-copying t)'
--8<---------------cut here---------------end--------------->8---

Provoke the error on a remote host. Describe in detail, which steps you
have performed in order to see the error.

There will be a Tramp debug buffer. Pls send it as attachment here.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.