Re: Mutt can not delete mails
On Fri 12 Nov 2021 at 15:03:24 (-0500), Greg Wooledge wrote: > On Fri, Nov 12, 2021 at 08:58:18PM +0100, Hans wrote: > > Greg Wooledge: > > > chmod 1777 /var/tmp > > > > Yes, that works, of course! But I do not understand why the settings are > > wrong. > > You said you've got /var on a separate partition. Was it always that > way (i.e. you created a /var partition during the installation)? Or > did you create a separate /var later on, and move the content over to it? > > If it was done by the installer, then one wonders which installer it > was exactly, and whether the results are reproducible. Earlier: > > ls -la / | grep var > > drwxr-xr-x 13 root root 4096 2. Sep 18:37 var Interesting that /var was modifed so recently. It's quite usual for /var to remain unmodified after installation, unless one makes a major change in configuration. So is Sept 2nd the date that the OP installed their system? Cheers, David.
Re: Mutt can not delete mails
On Fri, Nov 12, 2021 at 08:58:18PM +0100, Hans wrote: > Greg Wooledge: > > chmod 1777 /var/tmp > > Yes, that works, of course! But I do not understand why the settings are > wrong. You said you've got /var on a separate partition. Was it always that way (i.e. you created a /var partition during the installation)? Or did you create a separate /var later on, and move the content over to it? If it was done by the installer, then one wonders which installer it was exactly, and whether the results are reproducible.
Re: Mutt can not delete mails
Greg Wooledge: chmod 1777 /var/tmp Yes, that works, of course! But I do not understand why the settings are wrong. I never changed these, so this could only be happened at some upgrade, but the this should be discovered by other people, too. However, maybe other applications do never use /var/tmp, so no one could notice it. Thanks for it anyway! Best regards Hans
Re: Mutt can not delete mails
On Fri, Nov 12, 2021 at 07:06:26PM +0100, Hans wrote: > No, it is not /tmp, but /var/tmp. See here from the output: > [2021-11-11 22:08:39] ../../mbox.c:895: mutt_mktemp returns "/var/tmp/mutt- > protheus2-1000-47311-14301765248385272183". > [2021-11-11 22:08:39] Temporärdatei konnte nicht erzeugt werden! > [2021-11-11 22:08:44] Sortiere Postfach … > [2021-11-11 22:08:44] /var/mail/myusername kann nicht geschrieben werden! > Note, that /var is on its own partition. The rights settings are: > > ls -la / | grep var > drwxr-xr-x 13 root root 4096 2. Sep 18:37 var Just use ls -ld /var > ls -la /var/ | grep tmp > drwxr-xr-x 26 root root 12288 12. Nov 18:53 tmp Use ls -ld /var/tmp > So I do not have the right, to create files in /var/tmp. I wonder, if either > the mutt settings are wrong, or the settings of /var and /var/tmp. These permissions are wrong for /var/tmp. This is your problem. unicorn:~$ ls -ld /var/tmp drwxrwxrwt 6 root root 4096 Nov 12 13:47 /var/tmp To fix it, run this as root: chmod 1777 /var/tmp
Re: Mutt can not delete mails
Am Donnerstag, 11. November 2021, 21:53:53 CET schrieb Greg Wooledge: No, it is not /tmp, but /var/tmp. See here from the output: [2021-11-11 22:08:33] mutt_addr_is_user: no, all failed. [2021-11-11 22:08:33] mutt_addr_is_user: no, all failed. [2021-11-11 22:08:36] mutt_index_menu[807]: Got op 167 [2021-11-11 22:08:39] /var/mail/myusername wird geschrieben … [2021-11-11 22:08:39] Sortiere Postfach … [2021-11-11 22:08:39] ../../mbox.c:895: mutt_mktemp returns "/var/tmp/mutt- protheus2-1000-47311-14301765248385272183". [2021-11-11 22:08:39] Temporärdatei konnte nicht erzeugt werden! [2021-11-11 22:08:44] Sortiere Postfach … [2021-11-11 22:08:44] /var/mail/myusername kann nicht geschrieben werden! [2021-11-11 22:08:44] mutt_addr_is_user: no, all failed. [2021-11-11 22:08:44] mutt_addr_is_user: no, all failed. [2021-11-11 22:08:44] mutt_addr_is_user: no, all failed. Sorry, it is in German and I changed my username to "myusername". Note, that /var is on its own partition. The rights settings are: ls -la / | grep var drwxr-xr-x 13 root root 4096 2. Sep 18:37 var ls -la /var/ | grep tmp drwxr-xr-x 26 root root 12288 12. Nov 18:53 tmp So I do not have the right, to create files in /var/tmp. I wonder, if either the mutt settings are wrong, or the settings of /var and /var/tmp. Best regards Hans > On Thu, Nov 11, 2021 at 02:48:25PM -0600, David Wright wrote: > > There should be some indication at this point of why it can't > > delete your emails. The reason you see the filename > > /home/username/.mutt-cache/scratchpad/mutt-hostname… above is > > that I have set tmpdir="$HOME/.mutt-cache/scratchpad" in my > > muttrc file. I use that, rather than /tmp, because it is encrypted > > along with all of /home. But it means I have to clean it occasionally. > > If mutt normally writes these "temporary files" in /tmp (whaaat, how do > you guarantee an atomic move from /tmp to /var/mail??) then the OP > should at least check the perms and ownership of /tmp. > > ls -ld /tmp > > We've seen *so* many people with messed-up /tmp ownership lately.
Re: Mutt can not delete mails
On Thu 11 Nov 2021 at 15:53:53 (-0500), Greg Wooledge wrote: > On Thu, Nov 11, 2021 at 02:48:25PM -0600, David Wright wrote: > > There should be some indication at this point of why it can't > > delete your emails. The reason you see the filename > > /home/username/.mutt-cache/scratchpad/mutt-hostname… above is > > that I have set tmpdir="$HOME/.mutt-cache/scratchpad" in my > > muttrc file. I use that, rather than /tmp, because it is encrypted > > along with all of /home. But it means I have to clean it occasionally. > > If mutt normally writes these "temporary files" in /tmp (whaaat, how do > you guarantee an atomic move from /tmp to /var/mail??) then the OP > should at least check the perms and ownership of /tmp. > > ls -ld /tmp > > We've seen *so* many people with messed-up /tmp ownership lately. I assume it does check '$tmpdir'/$TMPDIR, but only when it requires its use, hence the message. After that, what can it do but give up syncing? I suppose it could treat deleting /all/ messages as a special case and truncate the file. One is warned about security risks with confidentiality from poor choice of tmpdir. I don't think it ever does a conventional atomic move (nor do I know the mechanism that one would use without having write access to the directory). I think it writes it back. Personally, it doesn't worry me what it does, because all the mail in my /var/mail/ is ephemeral stuff from APT, cron etc from this and my other hosts. All my /real/ mail is either on a remote IMAP server (different mechanism, presumably) or in local mailboxes also on /home. Therefore the most frequent use for my tmpdir is juggling files while composing replies. Cheers, David.
Re: Mutt can not delete mails
On Thu, Nov 11, 2021 at 02:48:25PM -0600, David Wright wrote: > There should be some indication at this point of why it can't > delete your emails. The reason you see the filename > /home/username/.mutt-cache/scratchpad/mutt-hostname… above is > that I have set tmpdir="$HOME/.mutt-cache/scratchpad" in my > muttrc file. I use that, rather than /tmp, because it is encrypted > along with all of /home. But it means I have to clean it occasionally. If mutt normally writes these "temporary files" in /tmp (whaaat, how do you guarantee an atomic move from /tmp to /var/mail??) then the OP should at least check the perms and ownership of /tmp. ls -ld /tmp We've seen *so* many people with messed-up /tmp ownership lately.
Re: Mutt can not delete mails
On Thu 28 Oct 2021 at 16:16:58 (+0200), Hans wrote: > Am Donnerstag, 28. Oktober 2021, 15:38:34 CEST schrieb Greg Wooledge: > [ … ] This is step-by-step what I do: > > Starting mutt from the commandline as normal user. Mutt in ncurses appears. > Now I want to mark and delete all mails. I press Shift+D, then it asks the > for > the sample and I press . (dot) and * (asterix). > > By pressing the "Enter" key all mails are marked ND+. > > Now pressing "q" (for quit) and it asks me "20 as deletion marked mails > delete? ([yes]/no):" (Note, I have a German environment, so it asks me in > German. This sentence a translated by me). > > I answer yes, and it appears "temporary file could not be created". > > Pressing again "q" and now answer "no", mutt closes. > > Does this help? Not much, because there's no location information. I think you should try running mutt with debugging set: $ mutt -d 5 … and whatever else you normally put here … This will generate a huge file called .muttdebug0, so don't do much more beyond deleting a single message (with d) and then syncing the mailbox (with $). Then quit, with x so that you don't get any more complaints. Now look at the end of .muttdebug0 file with less, and the last bit should include something like 'Got op 87' (for x) or 'Got op 151 Mailbox is unchanged' (if you typed q). Now search (backwards) for 'Writing /var/mail/', which should follow something like 'Got op 130' where 130 is the opcode for sync. Here's what you ought to see at this point: Got op 130 Writing /var/mail/username... Sorting mailbox... ../../mbox.c:869: mutt_mktemp returns "/home/username/.mutt-cache/scratchpad/mutt-hostname-1234-56789-1122334455667788990". updating progress: 0 Writing /var/mail/username... 0/31 (0%) Committing changes... 30 kept, 1 deleted. Sorting mailbox... and here's what I see when I temporarily make the mail file and its directory owned by root: Got op 130 Writing /var/mail/username... Sorting mailbox... Unable to lock mailbox! Sorting mailbox... If you're running mutt on bullseye, the opcodes might be different, hence searching for 'Writing /var/mail/' instead. There should be some indication at this point of why it can't delete your emails. The reason you see the filename /home/username/.mutt-cache/scratchpad/mutt-hostname… above is that I have set tmpdir="$HOME/.mutt-cache/scratchpad" in my muttrc file. I use that, rather than /tmp, because it is encrypted along with all of /home. But it means I have to clean it occasionally. Cheers, David.
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.
Re: Mutt can not delete mails
On Thu 28 Oct 2021 at 17:04:59 (+0100), Tixy wrote: > On Thu, 2021-10-28 at 17:48 +0200, Hans wrote: > > Oh, and I forgot to mention or make clear: > > > > The file /var/mail/myusername does not be reduzed to 0, and as the user > > myusername I can not manually delete this file, although (if I am not > > wrong!), > > I should be able to, as it is rw for me. > > You can't delete the file because that requires modifying the directory > containing it, i.e. /var/mail/ and you don't have permissions for that. > These are the permissions you showed us... > >ls -la /var/mail/ >drwxrwsr-x 2 root mail4096 28. Okt 15:12 *.* >drwxr-xr-x 13 root root4096 2. Sep 18:37 *..* >-rw-rw 1 myusername mail 2090109 28. Okt 15:02 myusername > > So /var/mail/ has owner 'root', group 'mail', and isn't writeable by > others. > > You do have permission to modify the contents of file 'myusername' as > you are the owner, and owner has write permission set. I think the OP has some difficulty with this concept, as they have made the same statement, had it corrected by Greg, and disputed it, as recently as May 6 and July 8 this year. I just tried changing the permissions on /var/mail/ to drwxr-sr-x 2 root mail 4096 mail and it seems unlikely that this is the OP's problem. The OP reports that they successfully marked messages as deleted, and was asked whether to actually delete them. Mutt would have marked the Index page with %, ie readonly, and objected to marking messages with the delete flag because mutt_dotlock would already have failed to create and delete a lockfile, viz: $ inotifywait -m /var/mail/ Setting up watches. Watches established. [ … ] [ Open /var/mail/username in mutt ] [ … ] /var/mail/ CREATE username.hostname.6695 /var/mail/ OPEN username.hostname.6695 /var/mail/ CLOSE_WRITE,CLOSE username.hostname.6695 /var/mail/ CREATE username.lock /var/mail/ DELETE username.hostname.6695 [ … ] /var/mail/ DELETE username.lock [ Mutt awaits user keystrokes ] If those lines are absent, the mailbox status is immediately shown as readonly (%). Disclaimer: I tried all this out just to generate a log of normal behaviour. (I try to keep good records of my unusual email setup.) This assumes that the system is as per Debian. I notice: https://lists.debian.org/debian-user/2016/10/msg00910.html Cheers, David.
Re: Mutt can not delete mails
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. (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) Tim.
Re: Mutt can not delete mails
On Thu, 2021-10-28 at 17:48 +0200, Hans wrote: > Oh, and I forgot to mention or make clear: > > The file /var/mail/myusername does not be reduzed to 0, and as the user > myusername I can not manually delete this file, although (if I am not > wrong!), > I should be able to, as it is rw for me. You can't delete the file because that requires modifying the directory containing it, i.e. /var/mail/ and you don't have permissions for that. These are the permissions you showed us... ls -la /var/mail/ drwxrwsr-x 2 root mail4096 28. Okt 15:12 *.* drwxr-xr-x 13 root root4096 2. Sep 18:37 *..* -rw-rw 1 myusername mail 2090109 28. Okt 15:02 myusername So /var/mail/ has owner 'root', group 'mail', and isn't writeable by others. You do have permission to modify the contents of file 'myusername' as you are the owner, and owner has write permission set. -- Tixy
Re: Mutt can not delete mails
On Thu, Oct 28, 2021 at 05:48:31PM +0200, Hans wrote: > Oh, and I forgot to mention or make clear: > > The file /var/mail/myusername does not be reduzed to 0, and as the user > myusername I can not manually delete this file, although (if I am not > wrong!), > I should be able to, as it is rw for me. Incorrect. Deleting a file requires write permissions on the directory it's in. The permissions on the file itself are irrelevent.
Re: Mutt can not delete mails
Oh, and I forgot to mention or make clear: The file /var/mail/myusername does not be reduzed to 0, and as the user myusername I can not manually delete this file, although (if I am not wrong!), I should be able to, as it is rw for me. Something special (maybe this is important): The directory /var resides on an own partition, which is luks encrypted. But on the other machine (32-bit) where mutt is working well, is the same partition structure. What did I miss? Best Hans
Re: Mutt can not delete mails
Am Donnerstag, 28. Oktober 2021, 16:48:20 CEST schrieb David Wright: Thank you for all the help! First of all, I checked, if there is a nuttrc in my ~/HOME, but there is none. But there is a Muttrc (yes, with capital letter) below /etc, so I suppose this takes the control. However, I never changed this, but maybe there is a configuration issue. The issue I described in my mails appeared in earlier times (one or tw years ago), and then after an updgrade everything worked fine. After a new upgrade (about 1 or 1,5 years ago), I remarked that issue again (I am not sure, but I think, I even wrote a bugreport on it, as I was sure, this was a bug). Since then there was no change, but it could be, that my existing /etc/Muttrc is bad, so that as an upgrade does not ovwerwrite a config file, the bug is in there. There is nothing secret, this is the content of my /etc/Muttrc: # # System configuration file for Mutt # # Default list of header fields to weed when displaying. # Ignore all lines by default... ignore * # ... then allow these through. unignore from: subject to cc date x-mailer x-url user-agent # Display the fields in this order hdr_order date from to cc subject # emacs-like bindings bind editor"\e"kill-word bind editor"\e" kill-word # map delete-char to a sane value bind editor delete-char # some people actually like these settings #set pager_stop #bind pager previous-line #bind pager next-line # Specifies how to sort messages in the index menu. set sort=threads # The behavior of this option on the Debian mutt package is # not the original one because exim4, the default SMTP on Debian # does not strip bcc headers so this can cause privacy problems; # see man muttrc for more info #unset write_bcc # Postfix and qmail use Delivered-To for detecting loops unset bounce_delivered set mixmaster="mixmaster-filter" # System-wide CA file managed by the ca-certificates package set ssl_ca_certificates_file="/etc/ssl/certs/ca-certificates.crt" # imitate the old search-body function macro index \eb "~b " "search in message bodies" # simulate the old url menu macro index,pager,attach,compose \cb "\ set my_pipe_decode=\$pipe_decode pipe_decode\ urlview\ set pipe_decode=\$my_pipe_decode; unset my_pipe_decode" \ "call urlview to extract URLs out of a message" # Show documentation when pressing F1 macro generic,pager " zcat /usr/share/doc/mutt/manual.txt.gz | sensible- pager" "show Mutt documentation" # show the incoming mailboxes list (just like "mutt -y") and back when pressing "y" # note: these macros have been subsumed by the function. # macro index y "?" "show incoming mailboxes list" # macro pager y "?" "show incoming mailboxes list" bind browser y exit # Handler for gzip compressed mailboxes # open-hook '\.gz$' "gzip -cd '%f' > '%t'" # close-hook '\.gz$' "gzip -c '%t' > '%f'" # append-hook '\.gz$' "gzip -c '%t' >> '%f'" # If Mutt is unable to determine your site's domain name correctly, you can # set the default here. (better: fix /etc/mailname) # # set hostname=cs.hmc.edu # If your sendmail supports the -B8BITMIME flag, enable the following # # set use_8bitmime # Use mime.types to look up handlers for application/octet-stream. Can # be undone with unmime_lookup. mime_lookup application/octet-stream # Upgrade the progress counter every 250ms, good for mutt over SSH # see http://bugs.debian.org/537746 set time_inc=250 # Allow mutt to understand References, Cc and In-Reply-To as headers in mailto: mailto_allow = cc in-reply-to references ## ## *** DEFAULT SETTINGS FOR THE ATTACHMENTS PATCH *** ## ## ## Please see the manual (section "attachments") for detailed ## documentation of the "attachments" command. ## ## Removing a pattern from a list removes that pattern literally. It ## does not remove any type matching the pattern. ## ## attachments +A */.* ## attachments +A image/jpeg ## unattachments +A */.*
Re: Mutt can not delete mails
On Thu 28 Oct 2021 at 10:33:58 (-0400), Greg Wooledge wrote: > I'm wondering, in particular, if there is some setting in mutt that > tells it to attempt to delete the inbox file if it reaches 0 messages, > and that perhaps you've enabled it. If so, you'll want to disable it. That /would/ be a bug, because: 3.257. save_empty Type: boolean Default: yes When unset, mailboxes which contain no saved messages will be removed when closed (the exception is $spoolfile which is never removed). If set, mailboxes ↑ are never removed. Note: This only applies to mbox and MMDF folders, Mutt does not delete MH and Maildir directories. Unless, that is, the OP has an unusual idea of what a $spoolfile is. Cheers, David.
Re: Mutt can not delete mails
On Thu, Oct 28, 2021 at 04:16:58PM +0200, Hans wrote: > Am Donnerstag, 28. Oktober 2021, 15:38:34 CEST schrieb Greg Wooledge: > Hi Greg, > > of course I can. This is step-by-step what I do: > > Starting mutt from the commandline as normal user. Mutt in ncurses appears. > Now I want to mark and delete all mails. I press Shift+D, then it asks the > for > the sample and I press . (dot) and * (asterix). > > By pressing the "Enter" key all mails are marked ND+. > > Now pressing "q" (for quit) and it asks me "20 as deletion marked mails > delete? ([yes]/no):" (Note, I have a German environment, so it asks me in > German. This sentence a translated by me). > > I answer yes, and it appears "temporary file could not be created". > > Pressing again "q" and now answer "no", mutt closes. > > Does this help? OK... that's not what I asked for, but let's see if I can reproduce it. I created an account named "tester", and installed procmail, and gave tester a ~/.qmail file containing "|preline procmail" to force delivery to /var/mail. Then I sent a message to it: unicorn:~$ echo test | mailx -s testing tester and verified delivery: tester@unicorn:~$ ls -la /var/mail total 12 drwxrwsr-x 2 root mail 4096 Oct 28 10:25 . drwxr-xr-x 13 root root 4096 Mar 3 2018 .. -rw-rw 1 tester mail 455 Oct 28 10:25 tester Then fired up mutt as tester: tester@unicorn:~$ export MAIL=/var/mail/tester tester@unicorn:~$ mutt I pressed D . * Enter q y Mutt exited cleanly, and wrote: 0 kept, 1 deleted. And now the mailbox is empty: tester@unicorn:~$ ls -la /var/mail total 8 drwxrwsr-x 2 root mail 4096 Oct 28 10:28 . drwxr-xr-x 13 root root 4096 Mar 3 2018 .. -rw-rw 1 tester mail0 Oct 28 10:25 tester This is all acting as I expect. Is there, perhaps, something in your .muttrc which is changing mutt's behavior? You could try repeating your test with the .muttrc file temporarily renamed, and see if you get the same result. I'm wondering, in particular, if there is some setting in mutt that tells it to attempt to delete the inbox file if it reaches 0 messages, and that perhaps you've enabled it. If so, you'll want to disable it. P.S. my system details: Debian 11 amd64 Linux unicorn 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux package mutt version 2.0.5-4.1 Locally installed (non-Debian) qmail (shouldn't matter here)
Re: Mutt can not delete mails
On Thu 28 Oct 2021 at 16:16:58 (+0200), Hans wrote: > Am Donnerstag, 28. Oktober 2021, 15:38:34 CEST schrieb Greg Wooledge: > [ … ] This is step-by-step what I do: > > Starting mutt from the commandline as normal user. Mutt in ncurses appears. > Now I want to mark and delete all mails. I press Shift+D, then it asks the > for > the sample and I press . (dot) and * (asterix). > > By pressing the "Enter" key all mails are marked ND+. > > Now pressing "q" (for quit) and it asks me "20 as deletion marked mails > delete? ([yes]/no):" (Note, I have a German environment, so it asks me in > German. This sentence a translated by me). > > I answer yes, and it appears "temporary file could not be created". > > Pressing again "q" and now answer "no", mutt closes. > > Does this help? Two possibilities spring to mind: 3.349. trash Type: path Default: (empty) If set, this variable specifies the path of the trash folder where the mails marked for deletion will be moved, instead of being irremediably purged. NOTE: When you delete a message in the trash folder, it is really deleted, so that you have a way to clean the trash. You've specified the trash in a place you can't write to, and, a little less likely: 3.56. delete Type: quadoption Default: ask-yes Controls whether or not messages are really deleted when closing or synchronizing a mailbox. If set to yes, messages marked for deleting will automatically be purged without prompting. If set to no, messages marked for deletion will be kept in the mailbox. Cheers, David.
Re: Mutt can not delete mails
Am Donnerstag, 28. Oktober 2021, 15:38:34 CEST schrieb Greg Wooledge: Hi Greg, of course I can. This is step-by-step what I do: Starting mutt from the commandline as normal user. Mutt in ncurses appears. Now I want to mark and delete all mails. I press Shift+D, then it asks the for the sample and I press . (dot) and * (asterix). By pressing the "Enter" key all mails are marked ND+. Now pressing "q" (for quit) and it asks me "20 as deletion marked mails delete? ([yes]/no):" (Note, I have a German environment, so it asks me in German. This sentence a translated by me). I answer yes, and it appears "temporary file could not be created". Pressing again "q" and now answer "no", mutt closes. Does this help? Best regards Hans > On Thu, Oct 28, 2021 at 03:21:47PM +0200, Hans wrote: > > Hi folks, > > > > I got into an issue with mutt. Problem is, mutt can not delete mails and I > > myself can not delete the file below /var/mail/. > > You are not *supposed* to delete your entire inbox file. You're only > supposed to modify it, potentially reducing the size of it to 0 bytes. > > That said, I've been using $HOME/Maildir/ for decades, so I don't know > how Debian currently manages the /var/mail/* mbox files that it defaults > to. /usr/bin/mutt_dotlock is setgid mail on my system, the same as > on yours. /var/mail is writable by group mail (same as yours), so that > appears to be OK. > > Can you give us more details? E.g. describe how you delete a single > message from your inbox in mutt, and exactly what mutt does when you > try it.
Re: Mutt can not delete mails
On Thu, Oct 28, 2021 at 03:21:47PM +0200, Hans wrote: > Hi folks, > > I got into an issue with mutt. Problem is, mutt can not delete mails and I > myself can not delete > the file below /var/mail/. You are not *supposed* to delete your entire inbox file. You're only supposed to modify it, potentially reducing the size of it to 0 bytes. That said, I've been using $HOME/Maildir/ for decades, so I don't know how Debian currently manages the /var/mail/* mbox files that it defaults to. /usr/bin/mutt_dotlock is setgid mail on my system, the same as on yours. /var/mail is writable by group mail (same as yours), so that appears to be OK. Can you give us more details? E.g. describe how you delete a single message from your inbox in mutt, and exactly what mutt does when you try it.
Mutt can not delete mails
Hi folks, I got into an issue with mutt. Problem is, mutt can not delete mails and I myself can not delete the file below /var/mail/. So I believe, this might be a settings problem, however on my other 32-bit-system it is working. Only on my 64-bit systems it is not working. These are the settings: ls -la /usr/bin/ | grep mutt -rwxr-xr-x 1 root root 1169552 6. Jun 21:11 mutt -rwxr-sr-x 1 root mail 14496 6. Jun 21:11 mutt_dotlock ls -la /var/mail/ insgesamt 2052 drwxrwsr-x 2 root mail4096 28. Okt 15:12 *.* drwxr-xr-x 13 root root4096 2. Sep 18:37 *..* -rw-rw 1 myusername mail 2090109 28. Okt 15:02 myusername ls -la /var/mail/ullhan63 -rw-rw 1 myusername mail 2090109 28. Okt 15:02 /var/mail/ullhan63 groups myusername lp uucp dialout fax cdrom floppy audio dip video plugdev games users powerdev debian-tor netdev scanner wireshark chipcard kismet cyberjack So, what is wrong? Or is this a bug in mutt itself? Mutt always mournes, that it can not create a temporary file, but I can not figure out, which or where this temporary file is going to be created. Any hints are welcome. Thanks for reading this. Best regards Hans
