Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #237071 > unrolled thread

Re: correct settings of /var/mail/user?

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: correct settings of /var/mail/user? The Wanderer <wanderer@fastmail.fm> - 2021-07-08 16:30 +0200
    Re: correct settings of /var/mail/user? Hans <hans.ullrich@loop.de> - 2021-07-08 16:50 +0200
      Re: correct settings of /var/mail/user? Greg Wooledge <greg@wooledge.org> - 2021-07-08 16:50 +0200
        Re: correct settings of /var/mail/user? David Wright <deblis@lionunicorn.co.uk> - 2021-07-08 18:00 +0200

#237071 — Re: correct settings of /var/mail/user?

[Multipart message — attachments visible in raw view] — view raw

On 2021-07-08 at 10:18, Hans wrote:

> Hi folks,
> 
> I ran into the problem with mutt. Mutt can not delete my mails due
> to the access rights.
> 
> Looks like something is not correct set. Can someone tell me the 
> correctsetting?
> 
> Mine are these at the moment:
> 
> ls -la / | grep var
> drwxr-xr-x  14 root root    4096 18. Mai 11:33 var

$ ls -lhd /var/
drwxr-xr-x 16 root root 4.0K Jul  4 14:17 /var/

So this looks OK.

> ls -la /var | grep mail
> drwxrwsr-x   2 root mail   4096  8. Jul 16:02 mail

$ ls -lhd /var/mail/
drwxrwsr-x 2 root mail 4.0K Jul  7 07:03 /var/mail/

Seems like this one does too.

> ls -la /var/mail/username
> 
> -rw-rw---- 1 myusername mail 55330396  8. Jul 16:02 /var/mail/myusername
> 
> (The term "myusername" is an alias for my real username)

$ lh /var/mail/wanderer
-rw-rw---- 1 wanderer mail 0 Jul  7 07:03 /var/mail/wanderer

So does this.


Unless there's something I'm not spotting, it doesn't look like the
issue is with file/directory permissions. Just offhand, comparing
against my own system, I'm not sure of exactly where to look.

(I don't use mutt myself, but I do read mail from this spool using
/usr/bin/mail (which is /usr/bin/bsd-mailx), so would presumably need
the same access - and I don't have the errors you're reporting.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [next] | [standalone]

#237074

Am Donnerstag, 8. Juli 2021, 16:27:38 CEST schrieb The Wanderer:
Zhat is strange, as I also can not delete the file /var/mail/myusername 
manually - just because of access rights.

IMO this should be possible also without mutt.

Best

Hans

> $ ls -lhd /var/
> drwxr-xr-x 16 root root 4.0K Jul  4 14:17 /var/
> 
> So this looks OK.
> 
> > ls -la /var | grep mail
> > drwxrwsr-x   2 root mail   4096  8. Jul 16:02 mail
> 
> $ ls -lhd /var/mail/
> drwxrwsr-x 2 root mail 4.0K Jul  7 07:03 /var/mail/
> 
> Seems like this one does too.
> 

> $ lh /var/mail/wanderer
> -rw-rw---- 1 wanderer mail 0 Jul  7 07:03 /var/mail/wanderer
> 
> So does this.
> 

[toc] | [prev] | [next] | [standalone]

#237076

On Thu, Jul 08, 2021 at 04:35:48PM +0200, Hans wrote:
> Am Donnerstag, 8. Juli 2021, 16:27:38 CEST schrieb The Wanderer:
> Zhat is strange, as I also can not delete the file /var/mail/myusername 
> manually - just because of access rights.

You're not supposed to be able to delete that file.  You should, however,
be able to truncate it to zero bytes in size.

The issue that most people face with centralized /var/mail (or
/var/spool/mail) mbox files is locking.  You can't create a "dot-lock"
file in the spool directory, for the same reason that you can't delete
your inbox (or create your inbox, if it doesn't already exist).

Therefore, mutt normally includes a locking helper program, which is
setgid mail (or whatever is needed on the target platform), which can
create/remove dot-lock files in the spool directory.

On Debian, it looks like this:

unicorn:~$ dpkg -L mutt | grep lock
/usr/bin/mutt_dotlock
/usr/share/man/man1/mutt_dotlock.1.gz
unicorn:~$ ls -ld /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root mail 14496 Jun  6 15:11 /usr/bin/mutt_dotlock*

If you're getting errors about locking failure, it could be because
you're missing this.

If you're getting errors about not being able to delete your inbox file,
ignore those.  Or file a bug report asking the developers to kindly
tell mutt not to try doing things it shouldn't be doing.

I have no idea whether my current version of mutt would try to delete
a central-spool mbox file if I removed all of the messages from it, for
two reasons: I am *so* far from having an empty inbox that the concept
of removing all the messages is ludicrous, and I don't use a central-spool
mbox file.  I'm using $HOME/Maildir/.

[toc] | [prev] | [next] | [standalone]

#237077

On Thu 08 Jul 2021 at 10:46:08 (-0400), Greg Wooledge wrote:
> On Thu, Jul 08, 2021 at 04:35:48PM +0200, Hans wrote:
> > Am Donnerstag, 8. Juli 2021, 16:27:38 CEST schrieb The Wanderer:
> > Zhat is strange, as I also can not delete the file /var/mail/myusername 
> > manually - just because of access rights.
> 
> You're not supposed to be able to delete that file.  You should, however,
> be able to truncate it to zero bytes in size.
> 
> The issue that most people face with centralized /var/mail (or
> /var/spool/mail) mbox files is locking.  You can't create a "dot-lock"
> file in the spool directory, for the same reason that you can't delete
> your inbox (or create your inbox, if it doesn't already exist).
> 
> Therefore, mutt normally includes a locking helper program, which is
> setgid mail (or whatever is needed on the target platform), which can
> create/remove dot-lock files in the spool directory.
> 
> On Debian, it looks like this:
> 
> unicorn:~$ dpkg -L mutt | grep lock
> /usr/bin/mutt_dotlock
> /usr/share/man/man1/mutt_dotlock.1.gz
> unicorn:~$ ls -ld /usr/bin/mutt_dotlock
> -rwxr-sr-x 1 root mail 14496 Jun  6 15:11 /usr/bin/mutt_dotlock*
> 
> If you're getting errors about locking failure, it could be because
> you're missing this.
> 
> If you're getting errors about not being able to delete your inbox file,
> ignore those.  Or file a bug report asking the developers to kindly
> tell mutt not to try doing things it shouldn't be doing.

A helpful summary.

> I have no idea whether my current version of mutt would try to delete
> a central-spool mbox file if I removed all of the messages from it, for
> two reasons: I am *so* far from having an empty inbox that the concept
> of removing all the messages is ludicrous, and I don't use a central-spool
> mbox file.  I'm using $HOME/Maildir/.

Likely not, on several counts:

. if you have "no idea", then it's unlikely that you've changed
  "save_empty" to no (the default),

. mutt doesn't remove a central-spool mbox file,

. mutt doesn't remove MH and Maildir directories.

But I'm not sure why the OP thinks they should be able to remove a
file from:      drwxrwsr-x   2 root mail   4096  8. Jul 16:02 mail
in their followup.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web