2

I have a QNAP TS-251 NAS with a pair of 4 GB drives set up as RAID 1, running as a server, mainly for backups. It has the default operating system, QTS 4.2.0 (2016/01/19), which I think is current. It's a customized flavor of Linux with a GUI interface that I run from my Windows desktop. It has IP number 169.254.100.101 on its Ethernet #1 port and 169.254.100.102 on its Ethernet #2 port.

As a client, I have an old Dell (Core 2 Duo T8100) laptop running Ubuntu 14.04 LTS. It's connected to the QNAP's #2 Ethernet port, and its IP number is 169.254.100.99.

Note: From here I'll include background details that can probably be skipped (but answer "Why would you do this?" questions I anticipate) in [brackets].

There's also a Windows desktop connected to the QNAP's #1 Ethernet port, which is involved with this only to run the QNAP's GUI. I can also use PuTTY from it to the QNAP if I need a command line

[The QNAP comes with several default shared folders: Download, Multimedia, Public, Recordings, Web, homes.]

I created a shared folder named CrashPlan on the QNAP server, and a mount point on the Ubuntu client named /mnt/QNAP-CrashPlan. I installed NFS client packages on the client with sudo apt-get install portmap nfs-client [and installed autofs with sudo apt-get install autofs in an unsuccessful attempt to diagnose problems].

Following advice in this question, I gave NFS access rights, host/IP/network 169.254.*, permission read/write, and squash option NO_ROOT_SQUASH. The anonymous boxes remained grayed out.

So, in the moment of truth, from the client, I tried sudo mount 169.254.100.102:/CrashPlan /mnt/QNAP-CrashPlan and sudo mount -t nfs 169.254.100.102:/CrashPlan /mnt/QNAP-CrashPlan, and got mount.nfs: Connection timed out in both cases.

In an attempt to diagnose the problem, I tried showmount -e 169.254.100.102, but it replied clnt_create: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused).

I've searched a lot and tried a lot, but I haven't found any further paths to diagnose the problem. Any ideas?

I will edit in more details as needed. Also, this might deserve a "qnap" tag, but I don't have create tag permission.

[XY problem details: The reason I named the shared folder that I created CrashPlan is that I tried to run the QNAP as a CrashPlan server. I wasn't able to get that to work except by mounting the CrashPlan folder as a Windows drive, using net use to mount it, and running a separate user-mode client instance of CrashPlan on Windows, because Windows doesn't allow services access to net use drives. Running the CrashPlan server on my old Ubuntu laptop with the QNAP mounted through NFS was described as a configuration that avoided that issue.]

  • on the qnap, did you do "Network Services" -> "NFS Service" -> "enable nfs"? Do you have a firewall (iptables) on your ubuntu? – meuh Jun 30 '16 at 14:49
  • Yes to enabling NFS on the QNAP. I haven't set up a firewall on the Ubuntu machine, unless it's there by default. Thanks for pointing me toward something I can investigate. – Steve Jun 30 '16 at 18:56
  • 1
    Are you 100% sure 169.254.* is valid setting? I'm not sure that wildcards are permitted in IP addresses. I'd try first with the specific IP address of your computer. I think the correct syntax for IP address ranges is actually 169.254.0.0/255.255.0.0. tldp.org/HOWTO/NFS-HOWTO/server.html. I tried using a wildcard, and it didn't work for me, so I just put the specific IP address in. I haven't tried the "slash plus mask" syntax. I'd be interested in seeing if that fixes your problem. – Michael Bylstra Aug 20 '16 at 4:46
  • 1
    This further confirms my suspicion that wildcards are not valid for IP addresses: linux.die.net/man/5/exports – Michael Bylstra Aug 20 '16 at 4:49
  • @MichaelBylstra, the cautions against wildcards look very helpful. I'll try it as soon as I have a chance to tinker with the configuration again. – Steve Aug 21 '16 at 7:37
0

I had this after a recent update. I disabled NFS4 on the Qnap and enabled it on the Qnap and then it worked for the client.

-1

IP addresses starting by 169.* are an error, you need to fix that first, maybe it can be fixed by setting a DHCP server on the NAS.

The rest should be OK after that.

  • ... or fixed IP addresses. Right, you ought to use 10.0.0.0/8 or 192.168.0.0/16 for these things. – Ned64 Jan 14 '18 at 23:21
  • 2
    169.* is possible. I think you probably mean to caution against the RFC5735 169.254.* range. – roaima Jan 15 '18 at 0:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.