NFS mounts with puppet creates error

470 views
Skip to first unread message

Axel Bock

unread,
Jul 31, 2012, 8:23:00 AM7/31/12
to puppet...@googlegroups.com
Hi group,

I am managing an NFS mount with puppet. And it does not work, and seriously I really don't see how this can work out nicely. First I make sure with a file {} class that the directory I want to mount exists. Cause it is used by the webserver it should belong to the wwwrun/www group on the system. No prob.

Then I mount the NFS share on the dir. No prob.

On the 2nd run of puppet though ... Error! The NFS mount point is "changed" over to root:root with 775 permissions (or 777? I don't remember). Puppet of course now wants to set the user:group of the dir ... and naturally fails.

So is there a way to keep this error from happening?


Thanks in advance & greetings,
Axel.

Christopher Wood

unread,
Jul 31, 2012, 6:24:21 PM7/31/12
to puppet...@googlegroups.com
(inline)

On Tue, Jul 31, 2012 at 05:23:00AM -0700, Axel Bock wrote:
> Hi group,
>
> I am managing an NFS mount with puppet. And it does not work, and
> seriously I really don't see how this can work out nicely. First I make
> sure with a file {} class that the directory I want to mount exists. Cause
> it is used by the webserver it should belong to the wwwrun/www group on
> the system. No prob.

This is changing the directory inode on the nfs client.

> Then I mount the NFS share on the dir. No prob.

Now the inode that your nfs client sees is on the nfs server. It is not the same inode that you just managed with puppet.

(I say inode, but depending on the nfs server it may not be a unix filesystem behind it.)

> On the 2nd run of puppet though ... Error! The NFS mount point is
> "changed" over to root:root with 775 permissions (or 777? I don't
> remember). Puppet of course now wants to set the user:group of the dir ...
> and naturally fails.

This is dependent on your nfs server settings. You likely have root_squash set by default (see 'man exportfs'), so any activity as the root user on the nfs client is mapped to a "nobody" or "nfsnobody" (uid 65535 or similar) on the nfs server. Check /etc/exports on the nfs server.

> So is there a way to keep this error from happening?

You can set no_root_squash on the export and run 'exportfs -a' on the nfs server. Then you might have to remount on the client end.

The broader issue is whether you should manage file permissions on the nfs client or the nfs server. I haven't decided myself, but if you do it on the server you won't have to reduce security by running no_root_squash. The mount will also arrive with the correct permissions.

> Thanks in advance & greetings,
> Axel.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> [1]https://groups.google.com/d/msg/puppet-users/-/tw1oa58dRhoJ.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
> References
>
> Visible links
> 1. https://groups.google.com/d/msg/puppet-users/-/tw1oa58dRhoJ

Axel Bock

unread,
Aug 1, 2012, 2:18:51 AM8/1/12
to puppet...@googlegroups.com, christop...@pobox.com
Hello Christopher,

that's a nice explanation. I thought only the contents _under_ .../nfs-mounted/ would be server-side, not the mount-point itself. Well you always learn more. no_root_squash is not an option, I will have a look as how to manage that properly on our server side.

Mainly I just want to have the directory to have the correct permission when it is not currently mounted.


Thanks & greetings,
Axel.
>    puppet-users+unsubscribe@googlegroups.com.

jcbollinger

unread,
Aug 3, 2012, 10:04:48 AM8/3/12
to puppet...@googlegroups.com, christop...@pobox.com


On Wednesday, August 1, 2012 1:18:51 AM UTC-5, Axel Bock wrote:

Mainly I just want to have the directory to have the correct permission when it is not currently mounted.


If those permissions are different from the ones that the exported directory has on the NFS server, then you have a tricky problem.  As Christopher described, Puppet cannot directly distinguish between the remote directory visible when it is mounted and the mount point directory visible when the remote directory is not mounted.  This is an intentional aspect of the Unix architecture and design.

Are you sure that you actually need to manage the mount point's permissions?  They do not matter as long as the remote directory is mounted, so perhaps ensuring the remote directory mounted would be sufficient.


John

Axel Bock

unread,
Aug 8, 2012, 1:38:34 AM8/8/12
to puppet...@googlegroups.com, christop...@pobox.com
Well, I am creating those directories using puppet, and when nothing's mounted I don't want to have to be root to mess around with them. Kind of annoying. I went for an exec/unless thing now, in which I simply set the permissions on the command line - unless the directory already exists :) . Not great, but working.

Thanks for your answer!
Reply all
Reply to author
Forward
0 new messages