If you want a share to use in windows, forget NFS, go to samba...
NFS can work in windows, but every time i tried i had problems with it (with external tools, with MS Windows Services for UNIX or with more recent windows server 2012). All are really just hacks to windows, not even MS gave me enough support when a NFS start failing on a server after 1 year ...
How I did it
Followed the instructions from several websites.
1) Firstly, Grab the "Services for unix for windows" from : http://www.microsoft.com/en-gb/download/details.aspx?id=274
2) Do a custom install, selecting only
NFS -> Server for NFS
Authentication tools for NFS -> User ...
$ sudo service rpcbind restart
...does work, but the "portmapper is not running" problem will reappear on the next reboot.
The bottom of this page has a fix that will survive a reboot, but be aware it will delete your /etc/exports. In short, backup your /etc/exports then:
sudo apt-get purge rpcbind
sudo apt-get install nfs-kernel-server
Then restore ...
I am running Raspbian Jessie Lite (released on Mar 18, 2016), and got the same issue. Here is my steps to completely fix this issue, even if after a reboot.
Firstly have a look at the init file for /etc/init.d/nfs-kernel-server, you should notice its start runlevel is 2,3,4,5.
Also look at the following files' start runlevel, which is S only. I changed ...
Does anyone know how much speed I would gain in the same scenario with a Pi3 (just about..)?
Only if the Pi currently does this with a very high processor usage, say 75%+. This would indicate it is working hard to deal with the encryption, and might benefit from more horse power there.
Otherwise, the bottleneck is the I/O, and as far as I am aware the Pi ...
A quick and dirt hack would be to edit /etc/rc.local and add "mount /mnt/media". This will automatically be carried out on boot. The correct way, I think, would be to add the nfs-common init script to the default runlevel. This can be done by using the update-rc.d command.
sudo update-rc.d nfs-common enable
The error might mean you can't mount it locally, even though it says server. Everything looks to be set up fine on the Synology.
You might just want to allow everybody on your LAN to access that share for now. In IP add this. Just to make sure restart it after changing settings on NFS.
I am not sure what the security tab does in synology ...
Well, I think I found the problem: the one who parses cmdline.txt does not like empty lines before the valid cmdline: I have that:
# <previous cmmdline line commented out>
changing it to:
# <previous cmmdline line commented out>
makes it work.
Whoa! Let's go through your list briefly:
1) SD cards are slow.
Slow is relative and I won't disagree, unless the "relative to" is NFS, in which case SD cards are blazingly fast. As in, even the worst SD card will still be 5-10x faster than the best average ethernet speed you are likely to get. WRT to wifi...multiply a few more times.
2) SD cards ...
NFS uses IP/Hostname based security so that means you should give permission on NFS server to clients. Permissions should be defined at /etc/exports file. Example /etc/exports file:
# Path Client IP (options)
If you're concerned about SD corruption, then I'd say leave swap on the NAS. Spinning disk is much better at handling constant read/write/rewrite operations than SD cards and the WD Red series is designed to act in a NAS system. That being said, SD cards are getting better at handling the larger number of IO operations, provided the SD card is of good ...
The newest raspbian is based on jessie, so you should change your source to jessie.
So just change
deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free
deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free
The underlying problem is the symlinks in /etc/rc*.d are scattered around a bit. Some of the suggestions above rely on remaking these links and, perhaps, they get made with more appropriate order. Sometimes. Try -
for i in rpcbind nfs-common nfs-kernel-server ; do find /etc/rc* -name "S*$i*"; done
to see when they are started. In reality, you only need ...
After evaluating tons of answers and threads about this topic I found a quite simple solution.
The problem is that the rpcbind service is not started. This can be achieved just by adding the correct dependencies for the nfs-kernel-server service.
Add an approipriate drop-in for this service. For example
As far as network file system go, reasonable options are AFAIK limited to NFS and SMB, and unless you need SMB features (like Windows compatibility) you should really go with NFS. It's much faster (and CPU time is something you'd rather spare on an RPi) and somewhat more stable than SMB. NFS v4 supports file locking.
Attaching a USB drive seems a ...
I log data to an SQLite3 database on a NFS filesystem with no problems. The only rule is one writer, multiple readers (to avoid the locking/locked database problem). To enforce that my reader programs use PRAGMA query_only;
There's some code at https://github.com/DougieLawson/RaspberryPi that demonstrates that.
I upgraded from Wheezy to Jessie and found that nfs wasn't mounting anymore.
I use mounting by editing fstab directly. This might not be an exact answer to your question, but it might fix your issue.
I've added the bold text to my existing mount entry.
192.168.123.123:/mnt/ext/some/dir /home/pi/for/example nfs4 _netdev,noauto,x-systemd.automount 0 0
You do not need multiple cores. NFS transfers usually only use one CPU/core. You will have already reached your Ethernet connection's limit before you hit your CPU limit. It only matters when you heavily encrypt your transfers or when the CPU is already at 100%.
Your single-core pi is more than enough. Even a Pi Zero is way more than enough. But, it wouldn'...
zImage is just a common name for a compressed kernel image.
U-boot is capable of loading and booting various kernel images formats. The arch linux one should be ok.
DTB files are compiled Device Tree files that the linux kernel uses to configure the hardware.
more on it here : http://elinux.org/Device_Tree
To configure U-boot I advise you to use the uEnv....
Security is in no way rpi spesific. There are a few things you can do;
Assume you are a small fish and no one will care to cause you trouble.
Use a proxy/vpn to access the server so baddies would have to hack ssh/vpn before exploiting any services you chose to run (this is all you need if only trusted people use the server)
jail each service with an open ...
Another option (requiring a little more work) that you may want to look into is AutoFS. AutoFS will allow you to configure mount points such that they are mounted automatically when the mount point is accessed and unmounted after some time of inactivity. When using this with NFS it can help you reduce your network traffic by only keeping that connection ...