savannah-hackers-public
[Top][All Lists]
Advanced

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

Re: [Savannah-hackers-public] download access for uploading files broken


From: Assaf Gordon
Subject: Re: [Savannah-hackers-public] download access for uploading files broken
Date: Thu, 23 Feb 2017 22:09:14 -0500

Hi Bob,

> On Feb 23, 2017, at 22:04, Bob Proulx <address@hidden> wrote:
> 
> Assaf Gordon wrote:
>> I'm leaning towards the possibility that it is related to 
>> secondary-groups/NFS issues,
>> such as:
>>  
>> http://unix.stackexchange.com/questions/206062/nfs-permission-problem-with-secondary-groups
> 
> It does look like the same problem.  Too bad there isn't a solution
> there.
> 
> We are using the -g manage-groups option with nfs.  And it has been
> working.  So it is strange that it would now be failed after a
> restart.
> 
> This won't be encouraging but I had this exact same problem on another
> system a couple of years ago and never figured it out.  Eventually the
> problem evaporated around me and I never knew what caused it.

I have the solution! (i think).

This guy deserves a beer!
 http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/

1. Because we DO use "--manage-gids" in download:/etc/default/nfs-kernel-server 
,
it means that rpc.mountd on download IGNORES the GIDs sent from download0
and fetches the group-ids by itself.

2. Which groups are fetched for each user can be checked here:

  # cat /proc/net/rpc/auth.unix.gid/content                                     
                                
  #uid cnt: gids...
  0 1: 0
  131035 0:
  33 1: 33
  65534 1: 65534

I'm user "131035(agn)", and it found no groups for me.

Where do groups come from?
MySQL on internal0 ! which was just rebooted!

Then, checking download:/var/log/daemon.log shows clearly:
===
Feb 24 03:03:25 download mountd[4812]: libnss-mysql: Connection to server 
'208.118.235.75' failed: Lost connection to MySQL server at 'reading initial 
communication packet', system error: 113
===

and 208.118.235.75 is old 'internal' which was shutdown!

so somehow, "rpc.mountd" running on old download didn't get the memo :)

And while other user-space programs on 'download' did use the correct mysql on 
'internal0',
rpc.mountd did not! or at least, someone the reboot messed things up.


I would guess that perhaps just restarting rpc/nfs on download would fix it ??

But 'download' is too delicate for me to touch.
Also: should the NFS on download0 be unmounted first?

Fingers crossed!
 - assaf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]