Re: Mutt can not delete mails
On Thu 28 Oct 2021 at 17:17:19 (+0100), Tim Woodall wrote:
> On Thu, 28 Oct 2021, Hans wrote:
> >
> > I answer yes, and it appears "temporary file could not be created".
> >
> > Pressing again "q" and now answer "no", mutt closes.
> >
> > Does this help?
>
> check the ownership/permissions on /tmp
>
> Should be:
> drwxrwxrwt 12 root root 8192 Oct 28 17:05 .
>
> I've noticed some issues with upgrading ancient original installs (some
> going all the way back to potato) where /tmp doesn't have the correct
> permission but the system has worked perfectly prior to upgrade.
>
> I've not tried to investigate - I don't know if the permission/ownership
> was always wrong or has been changed as part of the upgrade.
I'd be very surprised were that the case with stable. It hasn't
happened to me, and I think that you'd immediately see a lot of
complaints if it happened.
But your advice to check is good. We can't assume that the OP hasn't
changed the temporary directory location, as it can be changed outside
of mutt's configuration files:
3.347. tmpdir
Type: path
Default: (empty)
This variable allows you to specify where Mutt will place its temporary files
needed for displaying and composing messages. If this variable is not set, the
environment variable $TMPDIR is used. If $TMPDIR is not set then “/tmp” is
used.
However, I've opened my local mailbox, deleted messages, and quit,
all without any file manipulations in /tmp/ (my $TMPDIR is unset).
> (One possibility would have been that /tmp was, for some unknown reason,
> owned by me as mode 775 and got changed to root.root mode 775 instead of
> mode 1777. These problem systems are sufficiently old that it's
> perfectly possible that I hacked something I didn't understand all
> those years ago when writing to /tmp failed)
>From what I've read (over decades¹), a frequent cause is to run
something like an installation script in the wrong directory,
like /tmp, often because an unchecked cd command failed.
Unpacking an archive can then change the permissions; eg from
man tar:
Overwrite control
These options control tar actions when extracting a file over an existing copy on disk.
[ … ]
--no-overwrite-dir
Preserve metadata of existing directories.
[ … ]
--overwrite-dir
Overwrite metadata of existing directories when extracting (default).
Disclaimer: As far as the OP is concerned, I notice that their system
has suffered unaccountable changes in permission settings before, eg:
https://lists.debian.org/debian-user/2014/07/msg00059.html
¹ eg https://lists.debian.org/debian-user/1997/11/msg01557.html
Cheers,
David.
Reply to: