[946] in athena10

home help back first fref pref prev next nref lref last post

Re: Permissions on /mit?

daemon@ATHENA.MIT.EDU (Evan Broder)
Sat Jan 24 01:07:06 2009

Message-ID: <497AAFCF.6090902@mit.edu>
Date: Sat, 24 Jan 2009 01:06:07 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Brian Neltner <neltnerb@mit.edu>
CC: debathena@mit.edu
In-Reply-To: <1232776882.4554.5.camel@gibbs-duhem>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Are you sure that any other pyhesiodfs's that were running were
umounted? You can run `mount | grep pyhesiodfs` to confirm.

And /mit is still owned root:pyhesiodfs with the permissions set to 775?

- Evan

Brian Neltner wrote:
> neltnerb@belcher10:~$ cd /
> neltnerb@belcher10:/$ sudo -u pyhesiodfs /usr/bin/pyhesiodfs -f /mit/
> fusermount: mount failed: Operation not permitted
> Traceback (most recent call last):
>   File "/usr/bin/pyhesiodfs", line 141, in <module>
>     main()
>   File "/usr/bin/pyhesiodfs", line 138, in main
>     server.main()
>   File "/usr/lib/python2.5/site-packages/fuse.py", line 713, in main
>     main(**d)
> fuse.FuseError: filesystem initialization failed
>
> On Sat, 2009-01-24 at 00:59 -0500, Evan Broder wrote:
>   
>> Hmm...try doing `cd /` and then `sudo -u pyhesiodfs /usr/bin/pyhesiodfs
>> -f /mit`
>>
>> - Evan
>>
>> Brian Neltner wrote:
>>     
>>> neltnerb@belcher10:~$ sudo -u pyhesiodfs /usr/bin/pyhesiodfs -f /mit
>>> fusermount: failed to open current directory: Permission denied
>>> Traceback (most recent call last):
>>>   File "/usr/bin/pyhesiodfs", line 141, in <module>
>>>     main()
>>>   File "/usr/bin/pyhesiodfs", line 138, in main
>>>     server.main()
>>>   File "/usr/lib/python2.5/site-packages/fuse.py", line 713, in main
>>>     main(**d)
>>> fuse.FuseError: filesystem initialization failed
>>>
>>> neltnerb@belcher10:/etc$ ls -l fuse.conf
>>> lrwxrwxrwx 1 root root 19 2009-01-24 00:22 fuse.conf ->
>>> fuse.conf.debathena
>>>
>>> neltnerb@belcher10:/etc$ ls -l fuse.conf.debathena
>>> -rw-r--r-- 1 root root 17 2008-11-20 19:30 fuse.conf.debathena
>>>
>>> neltnerb@belcher10:/etc$ cat fuse.conf
>>> user_allow_other
>>>
>>> On Sat, 2009-01-24 at 00:54 -0500, Evan Broder wrote:
>>>   
>>>       
>>>> Well, I'm not sure, but this is only a temporary fix. For starters, you
>>>> were running pyhesiodfs as root instead of as the pyhesiodfs user. What
>>>> if you kill that session with `sudo umount /mit` and then run `sudo -u
>>>> pyhesiodfs /usr/bin/pyhesiodfs -f /mit`?
>>>>
>>>> Was anything printed out to the window you ran pyhesiodfs from?
>>>>
>>>> Oh - also, while we're at it, what are the contents of /etc/fuse.conf?
>>>>
>>>> - Evan
>>>>
>>>> Brian Neltner wrote:
>>>>     
>>>>         
>>>>> Doing that allows me to add matlab and access /mit
>>>>>
>>>>> What changed by doing it this way?
>>>>>
>>>>> On Sat, 2009-01-24 at 00:42 -0500, Evan Broder wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> /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
>>>>>>>>>>>>>
>>>>>>>>>>>>>   
>>>>>>>>>>>>>       
>>>>>>>>>>>>>           
>>>>>>>>>>>>>               
>>>>>>>>>>>>>                   
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>>>>>>>>>>   
>>>>>>>>>>>       
>>>>>>>>>>>           
>>>>>>>>>>>               
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>   

home help back first fref pref prev next nref lref last post