Host should be *. That allows any host to connect. (public) Unless you want a specific host to be the one doing the connecting over NFS. (then put its IP there.)
You DO want write access, otherwise files cannot be created or edited on the share.
The syntax for mounting an NFS mount is more in line with what you quoted prior–
RE-reading your query, the (*) on the end of the share is something to be omitted. The source you got them from used them to draw attention, nothing else. Having them on will likely prevent it from mounting properly.
Also, Username and password options are not strictly necessary, unless you have a specific need to have your user credentials be something other than what they are on the connecting unix-like system. (That is one of the benefits of using NFS after all, you get REAL, and PROPER permissions enforcement.)
NFS uses a combination of “allowed hosts”, and native unix permissions to determine who has access to what.
EG, you can say “Only the computer with the address 192.168.1.50 can connect to this share” by setting that in the host section of the dashboard. (on real unix/linux hosts, this is controlled by the file /etc/exports)
Now, many users can be active on that host. The host can mount the share, but how do you keep UserA from smashing UserB’s data, and vise versa? The answer, is “The same way you do that in the local file system.” eg, with native file system permissions. The connecting device enforces the permissions the same way it enforces them on the local disk.
So, when attaching to an NFS share, the username and password options are irrelevant. That part is controlled by they allowed host list (/etc/exports). Once attached, who gets to see what files, and do what with them, is controlled by the permissions on those files and folders. The system requires local authentication to use a user’s credentials, so since the user is already logged in, asking for credentials is redundant.
It is only there in case you NEED all files and folders created to be made specifically under a specific identity. (EG, this host is super trusted, and does backups or something-- and all ownership will always be for a root user, etc- no matter what local user is logged in at the console. This is not (or should not be) the case with your rPi-- you will get security benefits from having local users and groups for various daemons running. Passing a username and password with /etc/fstab at boot is not advisable in this use case.
EDIT:
I did not give a use-case specific fstab entry-- just a generic prototype that you had quoted earlier, just to point out that it was more syntax correct than the entry you were using, which was clearly for a CIFS mount. You will need to make it use-case specific yourself.
I’m learning, i guess slowly but surely, i’m no tech guy i’m just learning along the way. Let me show you the mount path i used which worked in fstab. I was able to see the drive in pi when I (ls) however I had the permission issues in couchpotato. I got the below path from a tutorial to mount NAS in fstab i just changed up server, share etc.
Now look at this… I created the new Movie, TV and Download folder by SSH into the NAS when i check the permissions as I said earlier it was 777 giving full permissions which was what I wanted. Now it just came to me that when i created this unless the path is mounted on the Rpi when I mkdir wdmycloud, the directories created wouldn’t be in that folder!
So I guess what I should be trying to do is mount the path from the NAS to the Rpi is this possible? my path looks like this when i checked the NAS… /mnt/HD/HD_a2/mediacenter. Any suggestions on how to do this?
On the MyCloud, the system creates symbolic links in the /nfs/ folder that point to locations on the internal hdd, which as you noted, is mounted at /mnt/HD/HDa_2 .
So, if you followed those symlinks, you see this:
/nfs/mediacenter → /mnt/HD/HDa_2/mediacenter
It does this so that it can give a different owner and group for the share, so it does not conflict with Samba’s requirements. Samba shares get symlinks simmilarly, but they go under /shares instead.
When you create a share on the MyCloud, it creates a folder in /mnt/HD/HDa_2, and makes the corresponding symbolic links that point there in /shares (and /nfs, if nfs is enabled). If the folder already exists, it just creates the symbolic links, and sets up the sharing system.
You cannot have both NFS and CIFS mounted at the same place!!
Do a mount without any options. It will tell you what filesystem is mounted. I will bet money that /home/osmc/wdmycloud is mounted with CIFS, given how that df string is structured.
Hahaha money i’m sure you will win… But look at it this way, NFS not mounted based on the df… Please note I have the external HDD connected to the RPi…
and this is what it looks like from mount, with no options.
192.168.0.2:/nfs/Public on /home/chromebook/NAS type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.2,mountvers=3,mountport=43320,mountproto=udp,local_lock=none,addr=192.168.0.2)
I would wager that you are still having problems because you are still mounting as CIFS.
in /etc/fstab, then reboot.
It should work after that.
It will mount to exactly the same place, just with NFS instead of CIFS. No need to pass any usernames, passwords, or charactersets. That is not how NFS does authentication. That should mount the share at /home/osmc/wdmycloud, and give you native unix permissions. You should be able to change permissions with the GUI even, if you have the fs permissions to do so. (root certainly does.)
the x-systemd.automount option tells systemd to make sure that all the needed stuff (network stack, et al) are up before attempting the mount.
osmc@PBFmedia:~$ mount
devtmpfs on /dev type devtmpfs (rw,relatime,size=370520k,nr_inodes=92630,mode=75 5)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /run type tmpfs (rw,relatime)
/dev/mmcblk0p2 on / type ext4 (rw,relatime,stripe=1024,data=ordered)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmod e=000)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xa ttr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatim e,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blki o)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,mem ory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,de vices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,fr eezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,ne t_cls)
systemd-1 on /home/osmc/wdmycloud type autofs (rw,relatime,fd=21,pgrp=1,timeout= 300,minproto=5,maxproto=5,direct)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,time out=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
systemd-1 on /boot type autofs (rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5, maxproto=5,direct)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/sda1 on /media/KODI MEDIA type fuseblk (rw,nosuid,nodev,relatime,user_id=0, group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks)
/dev/mmcblk0p1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437 ,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=75104k,mode=70 0,uid=1000,gid=1000)
You might have weak network connectivity. NFS wants to default to ‘hard’ mode mounts, which require a very reliable communication with the NFS server. Putting it in Soft or Intr (interruptable) mode can help with that when the medium is less reliable. (like wifi is.)
