FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Red Hat Linux

 
 
LinkBack Thread Tools
 
Old 02-03-2010, 01:01 PM
Bruce Lundberg
 
Default File permissions being stripped on new files

Hello all,

I'm having an issue that I've seen before on other OS's (Solaris), but I'm coming up blank on solving for an NFS mount shared from RedHat
I've googled this, and looked through all the FAQs and mail lists I can find.

The issue is this:

Whenever a new file is created from an NFS client to an NFS mounted file system, the group and world permissions are being stripped such that any new file created ends up with 0600 as the file permissions. On the server, I have tried various sharing options (all_squash, anonuid, anongid, no_acl) with no luck. I've looked at the underlying mount point ownership and permissions, checked the file system acl's (getfacl...they match the visible file system), and set the custom SELinux (not mine) config to permissive. The file system is on an LVM partition, and has an SELinux group assigned in /etc/fstab. I've unmounted it, and performed a vanilla mount (no options). No amount of trial and error is working. Any file created by any user on an nfs client machine creates files with 0600 permissions, and local users on the nfs server create files with permissions based off their umask settings. I originally thought it was due to mismatches in permissions from Windows to Linux (The ser!
ver also NFS shares to Windows 2K boxes using hclnfsd (PC/NFS)), but I confirmed the same issue between RedHat systems.

One thing I'm wondering from my reading. It's mentioned in many places that ownership should be root in most cases and not some other user. This entire file structure is owned by a user that is ONLY local to the server box (long story, but the box is isolated....no DNS and only local users and settings). I've been trying to get this problem solved and am running out of ideas.

Any thoughts would be greatly appreciated.

TIA

Bruce Lundberg
Sr Unix Systems Administrator

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 02-03-2010, 01:39 PM
Alan A
 
Default File permissions being stripped on new files

What are permissions on the shared directory on the NFS server, and on NFS
client? Did you try nolock option in the fstab? My NFS mounts are owned by
the user, no problems there, no need for them to be owned by root. Have you
checked NFS versions?


On Wed, Feb 3, 2010 at 8:01 AM, Bruce Lundberg <bwlundberg@comcast.net>wrote:

>
> Hello all,
>
> I'm having an issue that I've seen before on other OS's (Solaris), but I'm
> coming up blank on solving for an NFS mount shared from RedHat
> I've googled this, and looked through all the FAQs and mail lists I can
> find.
>
> The issue is this:
>
> Whenever a new file is created from an NFS client to an NFS mounted file
> system, the group and world permissions are being stripped such that any new
> file created ends up with 0600 as the file permissions. On the server, I
> have tried various sharing options (all_squash, anonuid, anongid, no_acl)
> with no luck. I've looked at the underlying mount point ownership and
> permissions, checked the file system acl's (getfacl...they match the visible
> file system), and set the custom SELinux (not mine) config to permissive.
> The file system is on an LVM partition, and has an SELinux group assigned in
> /etc/fstab. I've unmounted it, and performed a vanilla mount (no options).
> No amount of trial and error is working. Any file created by any user on an
> nfs client machine creates files with 0600 permissions, and local users on
> the nfs server create files with permissions based off their umask settings.
> I originally thought it was due to mismatches in permissions from Windows to
> Linux (The ser!
> ver also NFS shares to Windows 2K boxes using hclnfsd (PC/NFS)), but I
> confirmed the same issue between RedHat systems.
>
> One thing I'm wondering from my reading. It's mentioned in many places that
> ownership should be root in most cases and not some other user. This entire
> file structure is owned by a user that is ONLY local to the server box (long
> story, but the box is isolated....no DNS and only local users and settings).
> I've been trying to get this problem solved and am running out of ideas.
>
> Any thoughts would be greatly appreciated.
>
> TIA
>
> Bruce Lundberg
> Sr Unix Systems Administrator
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



--
Alan A.
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 02-03-2010, 01:40 PM
"Miner, Jonathan W (US SSA)"
 
Default File permissions being stripped on new files

Bruce;

> It's mentioned in many places that ownership should be root in most cases and not some other user.

That seems like a strange statement to make.

> This entire file structure is owned by a user that is ONLY local to the server box

One of the requirements of NFS is that the UID and GID numbers need to be consistent between the server and clients. If you have a bunch of mismatched numbers, then file and group ownership is going to look different whether you're looking at it from the server or from a specific client.

NFS can also be time sensitive, so use NTP to make sure that clocks are in sync between the server and clients.

- Jon

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 

Thread Tools




All times are GMT. The time now is 06:51 AM.

VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org