[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#765472: marked as done (nfs-common: idmapd doesn't map groups with names including (german) umlauts on nfs mounted volumes)



Your message dated Sat, 10 Dec 2022 20:00:49 +0100
with message-id <Y5TXYTgrxNqjXLYg@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 owner@bugs.debian.org
immediately.)


-- 
765472: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765472
Debian Bug Tracking System
Contact owner@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 ---

Reply to: