Mutt can not delete mails
Hans
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 mail 4096 28. Okt 15:12 .
drwxr-xr-x 13 root root 4096 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
Greg Wooledge
> 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/.
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.
Hans
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
David Wright
> Am Donnerstag, 28. Oktober 2021, 15:38:34 CEST schrieb Greg Wooledge:
> 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?
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.
Greg Wooledge
> 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?
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 mail 0 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)
David Wright
> 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.
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.
Hans
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
Hans
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<delete>" kill-word
bind editor "\e<backspace>" kill-word
# map delete-char to a sane value
bind editor <delete> delete-char
# some people actually like these settings
#set pager_stop
#bind pager <up> previous-line
#bind pager <down> 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 "<search>~b " "search in message bodies"
# simulate the old url menu
macro index,pager,attach,compose \cb "\
<enter-command> set my_pipe_decode=\$pipe_decode pipe_decode<Enter>\
<pipe-message> urlview<Enter>\
<enter-command> set pipe_decode=\$my_pipe_decode; unset my_pipe_decode<Enter>" \
"call urlview to extract URLs out of a message"
# Show documentation when pressing F1
macro generic,pager <F1> "<shell-escape> zcat /usr/share/doc/mutt/manual.txt.gz | sensible-pager<enter>" "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 <browse-mailboxes> function.
# macro index y "<change-folder>?<toggle-mailboxes>" "show incoming mailboxes list"
# macro pager y "<exit><change-folder>?<toggle-mailboxes>" "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 */.*
##
## This leaves "attached" image/jpeg files on the allowed attachments
## list. It does not remove all items, as you might expect, because the
## second */.* is not a matching expression at this time.
##
## Remember: "unattachments" only undoes what "attachments" has done!
## It does not trigger any matching on actual messages.
## Qualify any MIME part with an "attachment" disposition, EXCEPT for
## text/x-vcard and application/pgp parts. (PGP parts are already known
## to mutt, and can be searched for with ~g, ~G, and ~k.)
##
## I've added x-pkcs7 to this, since it functions (for S/MIME)
## analogously to PGP signature attachments. S/MIME isn't supported
## in a stock mutt build, but we can still treat it specially here.
##
attachments +A */.*
attachments -A text/x-vcard application/pgp.*
attachments -A application/x-pkcs7-.*
## Discount all MIME parts with an "inline" disposition, unless they're
## text/plain. (Why inline a text/plain part unless it's external to the
## message flow?)
##
attachments +I text/plain
## These two lines make Mutt qualify MIME containers. (So, for example,
## a message/rfc822 forward will count as an attachment.) The first
## line is unnecessary if you already have "attach-allow */.*", of
## course. These are off by default! The MIME elements contained
## within a message/* or multipart/* are still examined, even if the
## containers themselves don't qualify.
##
#attachments +A message/.* multipart/.*
#attachments +I message/.* multipart/.*
## You probably don't really care to know about deleted attachments.
attachments -A message/external-body
attachments -I message/external-body
##
# See /usr/share/doc/mutt/README.Debian for details.
source /usr/lib/mutt/source-muttrc.d|
Sorry, it is long.
Anything unusual?
Best
Hans
Greg Wooledge
> 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.
Deleting a file requires write permissions on the directory it's in.
The permissions on the file itself are irrelevent.
Tixy
> 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.
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 mail 4096 28. Okt 15:12 *.*
drwxr-xr-x 13 root root 4096 2. Sep 18:37 *..*
others.
You do have permission to modify the contents of file 'myusername' as
you are the owner, and owner has write permission set.
--
Tixy
Tim Woodall
>
> I answer yes, and it appears "temporary file could not be created".
>
> Pressing again "q" and now answer "no", mutt closes.
>
> Does this help?
>
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.
David Wright
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.
David Wright
> 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.
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)
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.
David Wright
> 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?
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.
Greg Wooledge
> 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.
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.
David Wright
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.
Hans
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
Greg Wooledge
> No, it is not /tmp, but /var/tmp. See here from the output:
> 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!
>
> 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.
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
Hans
> 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
Greg Wooledge
> Greg Wooledge:
> > chmod 1777 /var/tmp
>
> Yes, that works, of course! But I do not understand why the settings are
> wrong.
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.
David Wright
> > ls -la / | grep var
> > drwxr-xr-x 13 root root 4096 2. Sep 18:37 var
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.