> Thanks Assaf! Good debugging work!
Yes. That was the solution. After your changes I was able to
"unbusy" the mount point by killing the processes that were holding it
busy. Then unmount it. Then on download proper I stopped the nfs
daemon and double checked that all was dead. Then started
> I have the solution! (i think).
Yay!
> This guy deserves a beer!
> http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/
He did do a good write-up. :-)
> 1. Because we DO use "--manage-gids" in
> download:/etc/default/nfs-kernel-server ,
> it means that rpc.mountd on download
Joël Krähemann reported today to savannah-users that sftp upload was
not working. Of course this was disabled Nov-2016 due to security
concerns. I stated that scp and rsync were supported and recommended
using rsync.
Unfortunately I didn't test it before sending out that message.
Seeing Matt
I have installed the latest security kernel and rebooted the VMs onto
it. All of the services are operating normally.
Initially I ran the test suite and the "download" tests all failed.
The NFS mount had not happened at boot time. The problem was lack of
an IP address for "olddownload" at boot
Hello,
Regarding this: https://savannah.gnu.org/support/?109271
mwette$ scp nyacc-0.76.3.tar.gz* mwe...@dl.sv.nongnu.org:/releases/nyacc/
scp: /releases/nyacc/: No such file or directory
The new server (download0) was missing a symlink:
ln -s /srv/download /releases
I guess this was done
