[SOLVED] NFS Mount , Create Files with Server-side User + Group

ondoho · 10-03-2017, 01:38 AM

the relevant bits -
on the server 192.168.0.11
/etc/exports:

Code:

/srv/nfs 192.168.0.10(rw,async,crossmnt,subtree_check)
/srv/nfs/html 192.168.0.10(rw,async,no_root_squash,no_subtree_check)

/etc/fstab:

Code:

 /var/www/html /srv/nfs/html none bind 0 0

on the client 192.168.0.10
/etc/fstab:

Code:

 192.168.0.11:/srv/nfs/html /srv/nfs-fromserver/html nfs defaults 0 0
bindfs#/srv/nfs-fromserver/html /home/ondoho/html fuse force-user=ondoho,force-group=users,chgrp-ignore,chown-ignore,chmod-ignore 0 0

what i would like to achieve is that under /home/ondoho/html on the client machine, I can create files as a regular user, and their ownership gets translated to www-data (*) so that my nginx server (on the same machine as the nfs server) can read & serve them.

i use a very similar bindfs mount on the server internally and it works beautifully.

on the client, users and permissions don't translate properly. i'm not even sure if mounting the nfs share again with bindfs is the proper way to achieve this.

examples from the nfs client machine:

client as root:

Code:

# cd /srv/nfs-fromserver/html
# touch x
# ls -al
total 28K
drwxrwxr-x  7 nobody nobody 4.0K Oct  3 09:31 ./
drwxr-xr-x  3 root   root   4.0K Oct  2 23:44 ../
drwxrwx---  2 nobody nobody 4.0K Oct  3 09:31 blog/
drwxr-xr-x  2 nobody nobody 4.0K Oct  1 22:38 monitorix/
drwxrwx--- 11 nobody nobody 4.0K Sep 22 23:52 production/
drwxrwx---  2 nobody nobody 4.0K Oct  3 08:31 staging/
drwxr-xr-x  6 nobody nobody 4.0K Sep 29 22:12 stuff/
-rw-r--r--  1 root   root      0 Oct  3 09:25 x

client as user:

Code:

$ cd html
$ touch y
$ ls -al
total 36K
drwxrwxr-x   7 ondoho users 4.0K Oct  3 09:31 ./
drwx------ 113 ondoho users  12K Oct  3 07:41 ../
drwxrwx---   2 ondoho users 4.0K Oct  3 09:31 blog/
drwxr-xr-x   2 ondoho users 4.0K Oct  1 22:38 monitorix/
drwxrwx---  11 ondoho users 4.0K Sep 22 23:52 production/
drwxrwx---   2 ondoho users 4.0K Oct  3 08:31 staging/
drwxr-xr-x   6 ondoho users 4.0K Sep 29 22:12 stuff/
-rw-r--r--   1 ondoho users    0 Oct  3 09:25 x
-rw-r--r--   1 ondoho users    0 Oct  3 09:25 y

on the server:

Code:

$ cd /var/www/html/
$ ls -al
total 28K
drwxrwxr-x  7 www-data www-data 4.0K Oct  3 09:31 ./
drwxr-xr-x  3 root     root     4.0K Aug 12 21:59 ../
drwxrwx---  2 www-data www-data 4.0K Oct  3 09:31 blog/
drwxr-xr-x  2 www-data www-data 4.0K Oct  1 22:38 monitorix/
drwxrwx--- 11 www-data www-data 4.0K Sep 22 23:52 production/
drwxrwx---  2 www-data www-data 4.0K Oct  3 08:31 staging/
drwxr-xr-x  6 www-data www-data 4.0K Sep 29 22:12 stuff/
-rw-r--r--  1 root     root        0 Oct  3 09:25 x
-rw-r--r--  1 root     root        0 Oct  3 09:25 y

there is the crux.
I would need those 2 last files to be www-data:www-data!

like i said, i'm not even sure i need bindfs on the client to achieve this.
i have been fiddling with this for hours, tried various serverfault search results etc.
it would seem a common requirement, but somehow my duckduckgo-fu is not strong on this one.

(*) the server is debian jessie and uses www-data, the client is archlinux and uses http, but the numerical id is 33 on both.

IsaacKuo · 10-03-2017, 02:59 AM

What happens if you use a symlink instead of a bind mount, or you access it via the normal nfs mount point (not the bind mount point)?

IsaacKuo · 10-03-2017, 03:17 AM

Oh sorry - I didn't read carefully enough. The setup you're trying is different from what I was thinking.

What if you do the bind mount hack on the server side, rather than the client side? In other words, you set up your bind mount, and then use /etc/exports to export the bind mount? That seems more intuitive to me.

ondoho · 10-03-2017, 11:08 AM

Quote:

Originally Posted by IsaacKuo

What if you do the bind mount hack on the server side, rather than the client side? In other words, you set up your bind mount, and then use /etc/exports to export the bind mount? That seems more intuitive to me.

on the server, bindfs mounts the html folder to my home (as already mentioned), and the transformation of ownership works flawlessly.

what i haven't mentioned yet is that i have a second nfs mount for my home directory, so the html folder shows up under that.

unfortunately, viewed from the remote machine, the folder appears empty.

i'm not sure if this is exactly what you meant; i guess i could also try exporting the bindfs mount directly. i will get onto that right away.

but i'd like to get away from the actual situation and ask if there's any general recommendations how to achieve what i want?
i.e. solve the constant www-data-vs-normal-user-vs-root permission and ownership struggle?

i took inspiration from here:
https://www.digitalocean.com/communi...or-web-folders

IsaacKuo · 10-03-2017, 03:39 PM

I don't know what the general practice would be. For this sort of web development situation, I think the usual thing is to NOT directly edit a web site. I'd be doing modifications in a development copy, and using something like rsync to roll out changes all at once; by running the rsync command as the target user, all of the created files will be owned by the target user.

But that's a broader modification on your workflow, of course.

bindfs seems a kludge, as is use of samba or even something like a FAT32 (possibly looped) file system.

- - - - - MY SOLUTION FOLLOWS:

To my thinking, the most elegant solution would be an sshfs mount running as the target user. This turns the biggest annoyance of sshfs into an asset - the fact that every access through it is done as the user it connected as.

So, you have /home/www-data/webshare/ on all machines (including the web server). On every machine, you mount it with something like:

Code:

sshfs -o allow_other www-data@webserver:/var/www/html/ /home/www-data/webshare

Obviously, use key based authentication (without pass phrase) if you want to automate mounting this.

I feel this is an elegant solution because you don't have to fiddle with a lot of options to set the desired UID/GID/etc. You just specify the target user, and it just works. And also, the thing works the same on all computers - the web server itself and also all client machines. It even elegantly works the same over the internet if you wish to work on the web site on-the-go. (If you do this, then I'd recommend using a custom port for ssh.)

IsaacKuo · 10-03-2017, 03:45 PM

If you want to secure this a bit more, but also allow other users to mount and unmount the share, you could create a utility user with the required authorized keys. Then you configure "sudo" to allow the desired users to be able to run the following two commands (only) as the utility user:

Code:

sshfs -o allow_other www-data@webserver:/var/www/html/ /home/www-data/webshare

fusermount -u /home/www-data/webshare

Of course, if you're confident of your sudo configuration, you can have those run as root.

ondoho · 10-04-2017, 01:36 AM

thanks a lot.

i trobleshot some more last night, and it seems no matter how i put it, bindfs doesn't play nice with nfs; what works on the server does not work on the client.

instead of trying to fix this, i decided i can live with different file ownership, as long as all owners have the required access.
mostly this meant adding www-data to the user group (of the same name as the user; that's how debian does this):

`usermod -a -G ondoho www-data`

currently i'm not using any sevrer side scripting, but when i do i guess a second step would be to give files created by both users group write permissions - the keyword __umask__ floats around in my brain.

thanks for thinking & writing up the sshfs approach. i actually only just got away from using sshfs because i wanted filesystem sharing automated at boot time, and sshfs is not suitable for that.
maybe that's where the problem started...

IsaacKuo · 10-04-2017, 11:22 AM

I've used automatically mounted sshfs before. I didn't feel like fiddling around with /etc/fstab, so I just made it part of a startup script in KDE3 (or GNOME2 ... I don't remember exactly when I switched). I've always used auto login, so that was basically a boot time script for practical purposes.

ondoho · 10-05-2017, 01:22 PM

^ that's pretty much exactly what i used to do.
there were a few corner cases though where that wasn't quite perfect; or generally the whole approach seemed too "fiddly".
but as i said, after fixing the group permissions i'm happy with the current nfs-based solution.