Your message dated Sat, 10 Dec 2022 20:00:49 +0100
with message-id <y5txytgrxnqjx...@eldamar.lan>
and subject line Re: Bug#765472: nfs-common: idmapd doesn't map groups with
names including (german) umlauts on nfs mounted volumes
has caused the Debian Bug report #765472,
regarding nfs-common: idmapd doesn't map groups with names including (german)
umlauts on nfs mounted volumes
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
765472: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765472
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nfs-common
Version: 1:1.2.6-4
Severity: normal
Tags: l10n
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
situation:
nfs server (wheezy) with winbind and MS Active Directory integration.
nfs client (wheezy) with samba, winbind and MS Active Directory integration.
the nfs server is exporting a directory via nfs and group ownership set to some
AD groups.
AD is installed in german, thus using umlauts in some default groups, e.g.
"domänen-benutzer".
* What exactly did you do (or not do) that was effective (or
ineffective)?
chgrp some files/directories to such a group (tested with two groups containing
umlauts) on the nfs server side.
* What was the outcome of this action?
stat on the directories on the nfs server shows GID and group name correctly.
stat (or ls -l) on the client side sees GID 4294967294 (nogroup).
switching groups on the server side from a working group to one with umlauts
however doesn't ever change the GID on the client side, not even to nogroup.
* What outcome did you expect instead?
a correct mapping from the server side to the nfs client.
-- Package-specific info:
-- rpcinfo --
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 60854 status
100024 1 tcp 38982 status
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 7
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = netto.lan
Local-Realms = netto.lan
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
[Translation]
Method = nsswitch
-- /etc/fstab --
01nfs-01v.netto.lan:uportal/www /mnt/nfs/uportal/www nfs4
proto=tcp,sec=sys 0 0
-- /proc/mounts --
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
01nfs-01v.netto.lan://uportal/www /mnt/nfs/uportal/www nfs4
rw,relatime,vers=4,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.161.220.249,minorversion=0,local_lock=none,addr=10.161.220.250
0 0
-- System Information:
Debian Release: 7.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nfs-common depends on:
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-41+deb7u1
ii libc6 2.13-38+deb7u4
ii libcap2 1:2.22-1.2
ii libcomerr2 1.42.5-1.1
ii libdevmapper1.02.1 2:1.02.74-8
ii libevent-2.0-5 2.0.19-stable-3
ii libgssglue1 0.4-2
ii libk5crypto3 1.10.1+dfsg-5+deb7u2
ii libkeyutils1 1.5.5-3
ii libkrb5-3 1.10.1+dfsg-5+deb7u2
ii libmount1 2.20.1-5.3
ii libnfsidmap2 0.25-4
ii libtirpc1 0.2.2-5
ii libwrap0 7.6.q-24
ii lsb-base 4.1+Debian8+deb7u1
ii rpcbind 0.2.0-8
ii ucf 3.0025+nmu3
Versions of packages nfs-common recommends:
ii python 2.7.3-4+deb7u1
Versions of packages nfs-common suggests:
pn open-iscsi <none>
pn watchdog <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,
On Wed, Oct 15, 2014 at 01:56:37PM +0200, Norbert F wrote:
> Package: nfs-common
> Version: 1:1.2.6-4
> Severity: normal
> Tags: l10n
>
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
>
> * What led up to the situation?
> situation:
> nfs server (wheezy) with winbind and MS Active Directory integration.
> nfs client (wheezy) with samba, winbind and MS Active Directory integration.
>
> the nfs server is exporting a directory via nfs and group ownership set to
> some AD groups.
> AD is installed in german, thus using umlauts in some default groups, e.g.
> "domänen-benutzer".
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> chgrp some files/directories to such a group (tested with two groups
> containing umlauts) on the nfs server side.
>
> * What was the outcome of this action?
> stat on the directories on the nfs server shows GID and group name correctly.
> stat (or ls -l) on the client side sees GID 4294967294 (nogroup).
>
> switching groups on the server side from a working group to one with umlauts
> however doesn't ever change the GID on the client side, not even to nogroup.
>
> * What outcome did you expect instead?
> a correct mapping from the server side to the nfs client.
I assume this has been fixed since then, and there were some changes
e.g. to allow non-ASCII characters in NFSv4 domain name as well in
around 1.2.8. So closing this old bugreport. If though the issue is
still reproducible with a recent version, then please do reopen.
In sense of BTS housekeeping I'm first closing it now.
Regards,
Salvatore
--- End Message ---