[940] in athena10
Re: Permissions on /mit?
daemon@ATHENA.MIT.EDU (Evan Broder)
Sat Jan 24 00:43:39 2009
Message-ID: <497AAA58.7020207@mit.edu>
Date: Sat, 24 Jan 2009 00:42:48 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Brian Neltner <neltnerb@mit.edu>
CC: debathena@mit.edu
In-Reply-To: <1232775515.4554.1.camel@gibbs-duhem>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
/mit is the only thing that should be chgrp'd to pyhesiodfs. What
happens if you run `sudo /usr/bin/pyhesiodfs -f /mit` in one window, and
then try to access something in /mit from another window?
- Evan
Brian Neltner wrote:
> It looks like it is installed... I did aptitude purge of both
> debathena-pyhesiodfs and debathena-mit-automounter along with removing
> all of the other debathena-standard packages, but upon reinstalling it
> has the same behavior as before.
>
> Is there a way I can get it to report any errors that the automounting
> script returns? It is possible that some permissions on other files
> in /etc were changed that are causing difficulty, I accidentally changed
> a number of them to root:root, so if there were other files that were
> originally owned by pyhesiodfs or something else, that could cause a
> problem.
>
> Brian
>
> On Sat, 2009-01-24 at 00:10 -0500, Evan Broder wrote:
>
>> debathena-pyhesiodfs doesn't actually interact with AFS directly; it
>> gets locker information from Hesiod, so it should continue to work
>> regardless of whether or not AFS is working.
>>
>> Is there any chance that the debathena-pyhesiodfs package was
>> uninstalled somehow? What happens if you run `sudo aptitude install
>> debathena-pyhesiodfs`, just to make sure?
>>
>> - Evan
>>
>> Brian Neltner wrote:
>>
>>> This command returns nothing.
>>>
>>> It does have AFS on /afs type afs (rw) listed.
>>>
>>> On Fri, 2009-01-23 at 03:40 -0500, Evan Broder wrote:
>>>
>>>
>>>> When configured correctly, /mit is a FUSE filesystem, and all
>>>> attributes, including the owner and permissions of /mit itself, should
>>>> be controlled by the FUSE filesystem. The fact that yours is 770
>>>> root:pyhesiodfs instead of 755 root:root suggests that the /mit
>>>> automounter isn't running.
>>>>
>>>> What do you get if you run `mount | grep pyhesiodfs`?
>>>>
>>>> - Evan
>>>>
>>>> Brian Neltner wrote:
>>>>
>>>>
>>>>> Dear Evan,
>>>>>
>>>>> When I do that, I get this message again:
>>>>>
>>>>> neltnerb@belcher10:~$ sudo /etc/init.d/debathena-pyhesiodfs restart
>>>>> * Restarting Debathena /mit automounter debathena-pyhesiodfs
>>>>> [ OK ]
>>>>> neltnerb@belcher10:~$ cd
>>>>> neltnerb@belcher10:~$ renew
>>>>> Password for neltnerb@ATHENA.MIT.EDU:
>>>>> neltnerb@belcher10:~$ add matlab
>>>>> Cannot attach locker on /mit:
>>>>> directory /mit is group/other writable.
>>>>>
>>>>> and permissions on the directory /mit are reset to:
>>>>>
>>>>> drwxrwx--- 2 root pyhesiodfs 4096 2009-01-20 14:11 mit
>>>>>
>>>>> Is there anywhere else that I might have permissions confused? Does my
>>>>> user need to be a member of group pyhesiodfs? Is something supposed to
>>>>> be run setuid somehow?
>>>>>
>>>>> Thanks,
>>>>> Brian
>>>>>
>>>>> On Tue, 2009-01-20 at 15:48 -0500, Evan Broder wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi Brian -
>>>>>> It looks like the /mit automounter may not be running. Try running
>>>>>> `sudo /etc/init.d/debathena-pyhesiodfs restart`
>>>>>>
>>>>>> - Evan
>>>>>>
>>>>>> Brian Neltner wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Dear Tim et al,
>>>>>>>
>>>>>>> I'm installing a server for my lab that I'd like to have set up so that
>>>>>>> people can use it to access their athena lockers and run athena software
>>>>>>> there (for instance gaussian) with X forwarding, as well as to access
>>>>>>> their personal athena directories.
>>>>>>>
>>>>>>> I've been able to do this successfully at home, but when I do this on
>>>>>>> the lab server, it gives me this:
>>>>>>>
>>>>>>> neltnerb@belcher10:/$ renew
>>>>>>> Password for neltnerb@ATHENA.MIT.EDU:
>>>>>>> neltnerb@belcher10:/$ add matlab
>>>>>>> Cannot attach locker on /mit:
>>>>>>> directory /mit is group/other writable.
>>>>>>>
>>>>>>> I changed the permissions with chmod go-w /mit to remove the writable
>>>>>>> permissions and when I try again, it gives me this:
>>>>>>>
>>>>>>> neltnerb@belcher10:~$ add matlab
>>>>>>> matlab: Could not attach locker:
>>>>>>> Permission denied while symlinking /afs/athena.mit.edu/software/matlab
>>>>>>> to /mit/matlab
>>>>>>>
>>>>>>> The folder /afs/athena.mit.edu/software/matlab exists and is readable by
>>>>>>> my normal user account.
>>>>>>>
>>>>>>> The permissions right now on /mit look like this (after my
>>>>>>> modifications):
>>>>>>>
>>>>>>> drwxr-xr-x 2 root pyhesiodfs 4096 2009-01-20 14:11 mit
>>>>>>>
>>>>>>> My user account is not a member of pyhesiodfs, and I didn't try adding
>>>>>>> myself to that group because I don't know what it is.
>>>>>>>
>>>>>>> What are the permissions on /mit supposed to be?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Brian Neltner
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
