Mailing List Archive

NFSv4: failed to set ownership on spool file
Hi,

we run Exim with $spool_directory on a NFSv4 Share. I do not know the gory details
of NFSv4 and what operations are expected to work and which operations are expected to break.

- UID mapping seems to be enabled (the files have the right owner, if the id-mapping domains
on both sides match, otherwise they belong to "nobody").

- The filer is a Hitachi NAS.

- The tcpdump show a V4 SETATTR, but only for the owner (I'd have
expected the group too), AND the owner is numerical, not user@domain,
as I would have expected. The pcap file is attached.

Exim dies on spool file creation, here is the relevant port of the source:

/* Make sure the file's group is the Exim gid, and double-check the mode
because the group setting doesn't always get set automatically. */

if (fchown(data_fd, exim_uid, exim_gid))
log_write(0, LOG_MAIN|LOG_PANIC_DIE,
"Failed setting ownership on spool file %s: %s",
spool_name, strerror(errno));
(void)fchmod(data_fd, SPOOL_MODE);


My questions:

- Does anybody experience similar problems?

- How did you solve it?

- Would a code change be the right move?


A) if (stat() and wrong ownership)
chown(…) or die()

B) if (chown() or stat() and wrong ownership)
die()


I'd prefer B, as it has impact only on a limited range of
setups.


Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Re: NFSv4: failed to set ownership on spool file [ In reply to ]
On 29 Jan 2019, at 09:30, Heiko Schlittermann via Exim-users <exim-users@exim.org> wrote:
> - How did you solve it?

Have you got ‘superuser’ mapping switched on so root maps to UID 0 on the NFS server?

This is referred to as no_root_squash in the client mount options; I suspect you need to permit the NFS client to allow root access.

I could be wrong!

Graeme
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: NFSv4: failed to set ownership on spool file [ In reply to ]
Graeme Fowler via Exim-users <exim-users@exim.org> (Di 29 Jan 2019 11:03:19 CET):
> Have you got ‘superuser’ mapping switched on so root maps to UID 0 on the NFS server?

Processes with uid=0 can create and chown files on the share. So I'd
say, root_squash is not enabled.

> This is referred to as no_root_squash in the client mount options; I suspect you need to permit the NFS client to allow root access.

I'm not sure if it is up to the client to choose no_root_squash. I know
this as a option on the server side.

> I could be wrong!
Me too.

--
Heiko
Re: NFSv4: failed to set ownership on spool file [ In reply to ]
On 2019-01-29 at 10:30 +0100, Heiko Schlittermann via Exim-users wrote:
> - The tcpdump show a V4 SETATTR, but only for the owner (I'd have
> expected the group too), AND the owner is numerical, not user@domain,
> as I would have expected. The pcap file is attached.

It's showing a GETATTR, not a SETATTR, according to my tcpdump. I just
installed:
tcpdump version 4.9.2
libpcap version 1.9.0-PRE-GIT
and that's unchanged.

NFS request xid 281459612 216 getattr fh 0,0/22
NFS reply xid 281459612 reply ok 64 getattr ERROR: Permission denied
(connection close)

As to what to expect: there's what the protocol allows, and there's what
the OS supports. I'm not an NFSv4 expert, the last time I used NFS
professionally with email it was v3, but even there we had READDIR vs
READDIRPLUS and _how_ does the OS decide what to do?

In this case, GETATTR with major/minor devices of 0 and file descriptor
22 is issued, then you get permission denied on just the getattr, so the
OS isn't getting as far as failing at the chown (or this happened
after the chown? Incomplete trace, can't tell.)

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: NFSv4: failed to set ownership on spool file [ In reply to ]
Phil Pennock via Exim-users <exim-users@exim.org> (Mi 30 Jan 2019 03:00:25 CET):
> On 2019-01-29 at 10:30 +0100, Heiko Schlittermann via Exim-users wrote:
> > - The tcpdump show a V4 SETATTR, but only for the owner (I'd have
> > expected the group too), AND the owner is numerical, not user@domain,
> > as I would have expected. The pcap file is attached.
>
> It's showing a GETATTR, not a SETATTR, according to my tcpdump. I just
> installed:
> tcpdump version 4.9.2
> libpcap version 1.9.0-PRE-GIT
> and that's unchanged.
>
> NFS request xid 281459612 216 getattr fh 0,0/22
> NFS reply xid 281459612 reply ok 64 getattr ERROR: Permission denied
> (connection close)

Talking about the dump I atteched? There I get *using tshark*

1 0.000000 192.168.96.41 ? 192.168.96.220 NFS 274 V4 Call SETATTR FH: 0x95636125
2 0.000306 192.168.96.220 ? 192.168.96.41 NFS 122 V4 Reply (Call In 1) SETATTR Status: NFS4ERR_ACCESS
3 0.000396 192.168.96.41 ? 192.168.96.220 TCP 54 718 ? 2049 [ACK] Seq=221 Ack=69 Win=1483 Len=0

..

> In this case, GETATTR with major/minor devices of 0 and file descriptor
> 22 is issued, then you get permission denied on just the getattr, so the
> OS isn't getting as far as failing at the chown (or this happened
> after the chown? Incomplete trace, can't tell.)

And yes, tcpdump shows the same dump in another way:

17:05:25.648682 IP 192.168.96.41.718 > 192.168.96.220.2049: Flags [P.], seq 2803392546:2803392766, ack 1363314097, win 1483, length 220: NFS request xid 281459612 216 getattr fh 0,0/22
17:05:25.648988 IP 192.168.96.220.2049 > 192.168.96.41.718: Flags [P.], seq 1:69, ack 220, win 65535, length 68: NFS reply xid 281459612 reply ok 64 getattr ERROR: Permission denied
17:05:25.649078 IP 192.168.96.41.718 > 192.168.96.220.2049: Flags [.], ack 69, win 1483, length 0

Whom to trust more?
(Actually I used wireshark)
--
Heiko