January 6, 20179 yr I'm trying to use an unRAID server to handle user home directory automounts. I've already modified my go script to load all the packages I need and actually have NIS working. But fly in the ointment is working out two things, NFS options and file permissions. Each user has a share for their home directory. On login on an NIS client host, that gets automounted. The options (aka "Rule") is 192.168.3.0/24(rw,insecure). The share is being exported as private. On the client, the files show as a owned by nobody. However, newly created files show up correctly, e.g., [pre]2043 roland> ls -l wxbug.pl -rw-rw-rw-. 1 nobody users 2169 Apr 9 2015 wxbug.pl 2044 roland> ls -l foo.txt ls: cannot access foo.txt: No such file or directory 2045 roland> touch foo.txt 2046 roland> ls -l foo.txt -rw-rw-r--. 1 roland roland 0 Jan 5 21:24 foo.txt[/pre] Additionally, the whole tree shows us as world read-write [pre]2042 roland> ls -ld . drwxrwxrwx. 1 nobody users 12288 Jan 5 21:23 .[/pre] which is definitely not desirable. The files are effectively world read-write for any host in the network. I would really like unix file permissions honored here. How can I accomplish this?
January 6, 20179 yr NFS shares have nothing in common with SMB shares. A private NFS share can be setup for a public SMB share (or even not-shared) As for your permission and ownership issue, that's how NFS works. What you can do is change owner/permission of the topmost folder to be root and drwxr-x-r-x (755) via unRaid command line and make sure the share is exported with a squash_root option (That's by default I think) then make each client mount their own share such that /mnt + /user + /NFS_Share (root rwxr-xr-x) + /client1 (user1 rwx------) + /client2 (user2 rwx------) The world read write permission is something used by unRaid to simplify access, but is completely optional. Mine looks this: root@MediaStore:~# exportfs -v | grep Downloads -A1 /mnt/user/Downloads 192.168.2.0/24(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,fsid=117,sec=sys,rw,insecure,no_root_squash,no_all_squash) <world>(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=117,anonuid=99,anongid=100,sec=sys,ro,insecure,root_squash,all_squash) root@MediaStore:~# ls -ald /mnt/user/Downloads drwxrws--- 1 nobody users 459618 Jan 6 12:21 /mnt/user/Downloads/ Not exactly world read-write, but only machines in my subnet have write access, regardless of the wide open permissions. But all my SMB shares use nobody as the filesystem access user, even if the shares are marked private.
January 8, 20179 yr Author Since I've been doing NFS automounts in my network for a couple of decades now, I'm having trouble with the "that's how NFS works" because until I switched to unRAID it most certainly wasn't. Users are know via the NIS passwd map. I'm using the unRAID users. So I can log in to a second host using my unRAID user. Before switching to unRAID, it was a different NIS master. And a different NFS server hosting the files. Once the directory was mounted, linux file permissions and ownership were obeyed. And I ran samba for the home directories, too, but it was for convenience for the windows/mac hosts, not as actual home directories. The main point here is that this all worked with sane, expected permissions that actually restricted access. A host mounted the directory via NFS, but whether or not a user could read/write was determined by standard linux file permissions on NFS mounts. Now it's not. That doesn't really make sense to me; unRAID is still running linux, there's no obvious reason why it can't do this.
January 8, 20179 yr NIS maps - unRAID isn't designed to be part of a NIS domain. I'm guessing its because none of the core team members work with NIS domains. (I used to at work, until we moved to using an AD domain + LDAP) That said, NIS domains are not absolutely needed on a NAS/file server. Any NFS implementation will gladly operate using the uid/gid and std POSIX ACL: owner, group and others - read/write unRaid has some default expectations, that make sharing files simpler to the target market - NAS for Media at home. whether a user could read or write is still determined by std linux permissions. Even with the default samba shares, the underlying POSIX ACLs still control who has access to what. If you searched the forums you'd see people with issues about the nobody user restricting file manipulation of anything created by processes (like torrents, sync, etc) running in unRAID itself. The kicker is that shares by default are created with the nobody user as the owner - because the default shares (SMB) are guest shares - thus nobody user is what is used to read and write the files. If it were me, I'd keep the NIS master on a different box or VM, and just alter the permissions of top level NFS shares as needed. Maybe you can show us your settings for a share or two, the actual POSIX ACLs for them, what you expect on the clients and what you actually see on them.
January 8, 20179 yr Author So, I've tried playing with permissions on the unRAID server, [pre]root@Tower:/mnt/user# ls -ld roland maria drwxr-xr-x 1 maria users 4096 Jan 8 18:08 maria/ drwxr-xr-x 1 roland users 12288 Jan 7 20:58 roland/[/pre] Additionally, I ran chown and chmod to set everything owned by maria under /mnt/user/maria and by roland under /mnt/user/roland. And all directory permissions to 755 and all file permissions to 644. I changed the NFS export options to match what I originally has when it was all Fedora as both server and client, [pre]192.168.3.0/24(async,rw,no_root_squash,insecure,no_subtree_check)[/pre] auto.home is [pre]root@Tower:/mnt/user# ypcat auto.home -rw,soft,intr,tcp,context="system_u:object_r:user_home_t:s0" tower.rlent.pnet:/mnt/user/& [/pre] which is really set up for a Fedora client running selinux in enforcing mode. When I log in as roland, it looks okay. But it isn't because I can write to /home/maria [pre]2039 roland> touch /home/maria/foo.txt 2040 roland> ls -l /home/maria/foo.txt -rw-rw-r--. 1 roland roland 0 Jan 8 18:08 /home/maria/foo.txt 2041 roland> ls -ld /home/maria/ drwxr-xr-x. 1 maria users 4096 Jan 8 18:08 /home/maria/ 2042 roland> ls -ldZ /home/maria/ drwxr-xr-x. 1 maria users system_u:object_r:user_home_t:s0 4096 Jan 8 18:08 /home/maria/ [/pre] It's not at all obvious to me why it's doing this. syslog on the unRAID server [pre]Jan 8 18:07:29 Tower rpc.mountd[3561]: authenticated mount request from 192.168.3.35:965 for /mnt/user/roland (/mnt/user/roland) Jan 8 18:07:29 Tower ypserv[6636]: refused connect from 192.168.3.35:52693 to procedure ypproc_match (rlent.pnet,shadow.byname;-1) Jan 8 18:07:33 Tower rpc.mountd[3561]: refused mount request from 192.168.3.35 for /mnt/user/cvs (/): not exported Jan 8 18:07:33 Tower ypserv[6636]: refused connect from 192.168.3.35:39046 to procedure ypproc_match (rlent.pnet,shadow.byname;-1) Jan 8 18:07:58 Tower rpc.mountd[3561]: authenticated mount request from 192.168.3.35:865 for /mnt/user/maria (/mnt/user/maria) Jan 8 18:09:33 Tower rpc.mountd[3561]: authenticated unmount request from 192.168.3.35:905 for /mnt/user/maria (/mnt/user/maria) [/pre] I don't think the "refused connect" is relevant but I'm still trying to track that down. If only POSIX ACLs were in control, I shouldn't be able to write to /home/maria when logged in as roland. But I can.
January 8, 20179 yr Could you provide the output of exportfs -v in unRAID? I'm wondering if the NFS shares are setup as expected. Also, I'm not sure if the SELinux settings are supposed to have any effect, given the unRAID is not SELinux enabled.
January 9, 20179 yr Author In principle, the selinux part should be part of what the client does, i.e., it applies those properties on mount. But even if I remove the context= part, I still end up with permissions being ignored. [pre]2038 roland> touch /home/maria/foo.txt 2039 roland> ls -l /home/maria/foo.txt -rw-rw-r--. 1 roland roland 0 Jan 8 20:00 /home/maria/foo.txt 2040 roland> ls -ldZ /home/maria drwxr-xr-x. 1 maria users system_u:object_r:nfs_t:s0 4096 Jan 8 20:00 /home/maria 2042 roland> ypcat auto.home -rw,soft,intr,tcp tower.rlent.pnet:/mnt/user/&[/pre]
January 9, 20179 yr Author So, the trick is simple, though non-obvious to someone who's been doing NFS for a long time. You have to set the options as read-only, i.e., [pre]192.168.3.0/24(ro,...)[/pre] That works, normal permissions kick in and let me write to my directories but not to other people's. I found this here, http://lime-technology.com/forum/index.php?topic=22902.msg203687#msg203687, though some of the comments there are dated, e.g., we don't need to write a custom go script, the web form lets me put the options in just fine.
January 9, 20179 yr Author Ugh, no. Silly me. I checked only half of the issue. It sure "fixes" not being able to write in someone else's directory, but I can't write in mine either. So no, not a fix.
January 10, 20179 yr I'll try to simulate your issue with Fedora VMs, when I get off from work, but I'll need the settings of the unRAID exports (via the GUI or exportfs -v) - possibly the NIS packages you are using too.
January 10, 20179 yr Author For NIS, I'm using yptools-2.14-x86_64-7.txz. The export maps are [pre]root@Tower:/boot/custom/usr/share/packages# cat yp/auto.home * -rw,soft,intr,tcp,context="system_u:object_r:user_home_t:s0" tower.rlent.pnet:/mnt/user/& root@Tower:/boot/custom/usr/share/packages# cat yp/auto.master /home auto.home --timeout 60[/pre] And exportfs -v shows [pre]/mnt/user/maria 192.168.3.0/24(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,fsid=102,anonuid=99,anongid=100,sec=sys,rw,insecure,no_root_squash,no_all_squash) /mnt/user/roland 192.168.3.0/24(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,fsid=100,anonuid=99,anongid=100,sec=sys,rw,insecure,no_root_squash,no_all_squash)[/pre] Looks like unRAID is automaticaly adding "sec=sys,rw,insecure,no_root_squash,no_all_squash" so I should probably drop that from my config in the GUI. This is pretty close to what I had when it was all Fedora for both client and server. After yptools installed I have this in the go script [pre]echo 'rlent.pnet' > /etc/defaultdomain domainname rlent.pnet echo domain rlent.pnet server tower.rlent.pnet > /etc/yp.conf cp /boot/custom/usr/share/packages/yp/* /var/yp sed -e s/YP_SERVER_ENABLE=0/YP_SERVER_ENABLE=1/ -e s/-ypsetme// /etc/rc.d/rc.yp > /etc/rc.d/rc.yp.tmp && mv /etc/rc.d/rc.yp.tmp /etc/rc.d/rc.yp ( cd /var/yp; make ) bash /etc/rc.d/rc.yp start[/pre] The files in /boot/custom/usr/share/packages/yp are auto.master, auto.home, and the yp Makefile It was easiest to just copy a modified Makefile, but the patch is [pre]root@Tower:/boot/custom/usr/share/packages# diff -uw /var/yp/Makefile.new /var/yp/Makefile --- /var/yp/Makefile.new 2016-06-06 14:04:04.000000000 -0400 +++ /var/yp/Makefile 2017-01-09 00:02:20.408325116 -0500 @@ -91,8 +91,8 @@ NETGROUP = $(YPSRCDIR)/netgroup NETID = $(YPSRCDIR)/netid AMD_HOME = $(YPSRCDIR)/amd.home -AUTO_MASTER = $(YPSRCDIR)/auto.master -AUTO_HOME = $(YPSRCDIR)/auto.home +AUTO_MASTER = $(YPDIR)/auto.master +AUTO_HOME = $(YPDIR)/auto.home AUTO_LOCAL = $(YPSRCDIR)/auto.local TIMEZONE = $(YPSRCDIR)/timezone LOCALE = $(YPSRCDIR)/locale @@ -109,8 +109,9 @@ # If you don't want some of these maps built, feel free to comment # them out from this list. -all: passwd group hosts rpc services netid protocols netgrp mail \ - shadow publickey # networks ethers bootparams printcap \ + +all: passwd group hosts rpc services netid protocols netgrp shadow auto.home auto.master +# shadow publickey # networks ethers bootparams printcap \ # amd.home auto.master auto.home auto.local passwd.adjunct \ # timezone locale netmasks [/pre] Thanks for taking the time to give this a shot.
January 16, 20179 yr Sorry, but due to personal issues, I'm unable to devote time to look into this anymore. I'm still fairly sure something is misconfigured somewhere, just not obvious to what it was. I might revisit this once my issues have been resolved, but until then, sorry again.
Archived
This topic is now archived and is closed to further replies.