LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Reply
 
Search this Thread
Old 06-20-2007, 07:00 AM   #1
wayno
Member
 
Registered: May 2007
Location: Brisbane, Australia
Distribution: Fedora 8/9, Xandros (eeepc)
Posts: 110
Blog Entries: 1

Rep: Reputation: 15
Question User / Group permissions on NFS shares


I have a problem which is probably has a really simple solution but I can't seem to find it. I have a server running Fedora Core 5 with all my pictures, music, etc on. I have a laptop with Fedora 7 and my wife runs XP Pro on hers. We both have user accounts on the server and have a primary group of StoreUsers. She does most of the picture editing, etc so I have made her the owner of all data files, with StoreUsers as the group. She connects via Samba shares and mapped drives and has free reign on those files. So far so good.

I have an NFS share from the server mounted on my laptop via a line in /etc/fstab:
Code:
server:/mnt/store   /mnt/store    nfs   defaults        0 0
On the server in /etc/exports, I have:
Code:
mnt/store my_pc(rw,sync)
The data files on the server all have the following permissions:
Code:
-rwxrwxr-T  1 my_wife StoreUsers  928152 Dec 25 22:29 IMG_0061.JPG
I know there should be no need for them to be executable but neither of us can access them if they are not

I have created symbolic links in my home folder to folders inside this mounted share and can access all these files happily. However, I can't modify any files or move folders or any other 'write' operation.

I made sure that my user name, UID and password and the StoreUsers name and GID are the same on the F7 machine as the FC5 machine but I'm at a loss to understand what I'm doing wrong. Can anybody give me any pointers?
 
Old 06-21-2007, 12:43 AM   #2
jschiwal
Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654
A) Is your UID identical on both computers?
B) Does the StoreUser GID match on both computers as well?
C) How is /mnt/store mounted? What is the filesystem?
D) What are the permissions of the /mnt/store directory and the files inside?
 
Old 06-21-2007, 05:11 AM   #3
wayno
Member
 
Registered: May 2007
Location: Brisbane, Australia
Distribution: Fedora 8/9, Xandros (eeepc)
Posts: 110
Blog Entries: 1

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by jschiwal
A) Is your UID identical on both computers?
B) Does the StoreUser GID match on both computers as well?
C) How is /mnt/store mounted? What is the filesystem?
D) What are the permissions of the /mnt/store directory and the files inside?
Erm .........

Can I point you to http://www.linuxquestions.org/questi...15#post2794015 for answers to those questions
 
Old 06-22-2007, 12:25 AM   #4
jschiwal
Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654
Scratch A & B.

You showed the permissions of a file and not of the directory being shared. Why is the sticky bit set on a file?
I wonder if there can be a conflict when you share the same directory using both samba and nfs. The Samba Howto suggests disabling Level 2 oplocks on shares accessed by both windows and nfs clients if the Linux kernel doesn't support oplocks. For some files, like *.pst and database files, they recommend disabling oplocks.
Quote:
Originally Posted by Samba3Howto Section 17.3
If client-side caching is desirable and reliable on your network, you will
benefit from turning on oplocks. If your network is slow and/or unreliable,
or you are sharing your files among other file sharing mechanisms (e.g.,
NFS) or across a WAN, or multiple people will be accessing the same files
frequently, you probably will not benefit from the overhead of your client
sending oplock breaks and will instead want to disable oplocks for the share.
Code:
[ acctdata ]
     oplocks = False
     level2 oplocks = False
 
Old 06-23-2007, 03:40 AM   #5
wayno
Member
 
Registered: May 2007
Location: Brisbane, Australia
Distribution: Fedora 8/9, Xandros (eeepc)
Posts: 110
Blog Entries: 1

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by jschiwal
Scratch A & B.

You showed the permissions of a file and not of the directory being shared. Why is the sticky bit set on a file?
I wonder if there can be a conflict when you share the same directory using both samba and nfs. The Samba Howto suggests disabling Level 2 oplocks on shares accessed by both windows and nfs clients if the Linux kernel doesn't support oplocks. For some files, like *.pst and database files, they recommend disabling oplocks.


Code:
[ acctdata ]
     oplocks = False
     level2 oplocks = False
Thanks for the response. Again, not fully understanding the intricacies of NFS permissions, I found that it I set permissions recursively from the top level, I must set 1774, if I set 774 it doesn't work correctly. Folder permissions are as below:
Code:
drwxrwxr-T 134 my_wife StoreUsers  4096 Jun 11 12:32 Music
I have a script that runs nightly, resetting permissions to 1774 so I guess that's why the sticky bit is set on the files? My network is reliable but not so fast (54Mb wireless, normally running between 40-48Mbps). Different users accessing the same files at different times wouldn't normally be a problem so I'll look into oplocks and see if that can work for me.
 
Old 06-23-2007, 03:16 PM   #6
jschiwal
Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654
The sticky bit will only allow the owner and root to delete or rename a file.

If you try to edit a file directly on the share, the process may involve either renaming the file or deleting it before saving the new one. For example the program might actually rename the file you are editing "example.jpg" to "example.jpg~" and then save "example.jpg"

The sticky bit may just be doing its job. Maybe you could use acl's or not use the sticky bit on the directory being shared, losing that protection.

Normally the sticky bit is just used for the the directory being shared. Take a look at "ls -ld /tmp" and "ls -ld /tmp/*" Notice how /tmp has the stick bit set, but the subdirectories in /tmp don't. You might want to loose that cron job or change from 1775 to 0755. It's also not a good idea having files on a public share with their executable bit set. You shouldn't run programs on a shared writeable directory.

The executable bit is used differently for directories.
You will want to use 1774 on the directory itself. You need group executable rights on the directory to be able to enter it.
Use 0664 or 0660 for the files in the share and 0774 or 0770 for the subdirectories.

Give that a try. You should have read write access to the share but you may not be able to edit or delete files your wife made. If not, remove the sticky bit on the share.

Last edited by jschiwal; 06-23-2007 at 03:29 PM.
 
Old 06-24-2007, 05:33 AM   #7
wayno
Member
 
Registered: May 2007
Location: Brisbane, Australia
Distribution: Fedora 8/9, Xandros (eeepc)
Posts: 110
Blog Entries: 1

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by jschiwal
The sticky bit will only allow the owner and root to delete or rename a file.

If you try to edit a file directly on the share, the process may involve either renaming the file or deleting it before saving the new one. For example the program might actually rename the file you are editing "example.jpg" to "example.jpg~" and then save "example.jpg"

The sticky bit may just be doing its job. Maybe you could use acl's or not use the sticky bit on the directory being shared, losing that protection.

Normally the sticky bit is just used for the the directory being shared. Take a look at "ls -ld /tmp" and "ls -ld /tmp/*" Notice how /tmp has the stick bit set, but the subdirectories in /tmp don't. You might want to loose that cron job or change from 1775 to 0755. It's also not a good idea having files on a public share with their executable bit set. You shouldn't run programs on a shared writeable directory.

The executable bit is used differently for directories.
You will want to use 1774 on the directory itself. You need group executable rights on the directory to be able to enter it.
Use 0664 or 0660 for the files in the share and 0774 or 0770 for the subdirectories.

Give that a try. You should have read write access to the share but you may not be able to edit or delete files your wife made. If not, remove the sticky bit on the share.
I've changed my cron job to set perms to 770 now and it works fine. I realise why I ended up with the sticky bit set now; somewhere in my experiments I had been trying to set everything to 660 and as per your explanation of directory perms, I couldn't enter the directory. So when 1770 worked for me, it stuck. I've now got my perms set at 770 until I figure out how to set 660 on files and 770 only on folders. I tried:
Code:
chmod 660 `locate *.jpg`
on the Pictures folder but chmod complained that the input was too long. If that had worked I would have had to do the same with *.mov, *.gif and a few others but I'm just experimenting. For the time being though, both of us can now edit pics and move them around, so that's a huge plus.

Thanks heaps for your help.

Last edited by wayno; 06-24-2007 at 05:34 AM.
 
Old 06-24-2007, 06:11 AM   #8
jschiwal
Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654
You can use the find command to do it.

find /mnt/store -type f -exec chmod 0660 '{}' \;
find /mnt/store -type d -exec chmod 0770 '{}' \;
 
  


Reply

Tags
nfs, permissions


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
nfs shares and permissions windsurfer Linux - Software 1 04-17-2007 05:33 AM
user/group permissions prozac Linux - Newbie 4 11-20-2005 11:49 PM
Does anyone know why mounting NFS shares causes the directory permissions to change? gkneller Linux - Networking 4 01-29-2004 08:21 AM
User Group and samba shares Sylhouette Linux - General 0 01-09-2002 03:26 PM
user/group permissions Diane Welch Linux - Newbie 3 05-08-2001 07:03 AM


All times are GMT -5. The time now is 10:31 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration