[BUG] NFS connection is lost again and again

[keys&sax]

Hi,
At home I have the 209pro and 2 PCs with Ubuntu running. NFS is activated on the Qnap and on the PCs I modified the /etc/fstab to make the NFS-mount on startup.
Every few days (1 .. 3) the connection is not made when starting up a PC.
Restarting the connection on the PC (sudo mount -a) gives a permission denied. Only shutting down and restarting the Qnap makes a new NFS-connection possible.
Any suggestions?
The Qnap logs do show the mount information and don't show unmount lines
Are there other log-files that can give information?
Thanks.
Edwin

[schumaku]

Every few days (1 .. 3) the connection is not made when starting up a PC.

Is it feasible your NAS need do wake-up, and spin-up the sleeping disks?

When it fails the next time, please try to login to the Web UI first or try a manual SMB mount - if this succeeds, retry the NFS mount -a.

-Kurt.

[keys&sax]

Hi Kurt,
There it was, I just started up one of the PC's and none of the 6 mounts were made.
(The 2 PCs are running Ubuntu 8.04 and 8.10)

What I did in steps was:
1. on the PC >sudo mount -a > it states that the are no access rights (6 times) no mounts
2. logged into the Qnap as admin, checked IP adresses in NFS access control, they were ok
3. on the PC >sudo mount -a > no rights (6 x) no change
4. opened a document in one of the folders on the Qnap with the explorer through smb network
5. on the PC >sudo mount -a > no rights (6 x) no change
6. reduced the two allowed IP adresses to only one in 1 of 6 NFS-shared folders on the Qnap
7. on the PC >sudo mount -a > ALL 6 (!) folders now MOUNTED

It seams like making changes (in the allowed IP adresses in only one of the NFS shared folders) is making all the shared folders accessible again.
I use this format: 192.168.178.22, 192.168.178.25 here the last one was skipped.
(The other way to recover the NFS-mounts is to do a complete restart the Qnap.)

On occasions I had more problems with IP-adresses in NFS Access control. i.e. I have never been able to use wildcards as * or ? for the last digits. This has been there in all the major updates that there were in the last year.

The details of the Qnap are in the signature.

Let me know when I can supply you with more information.
Hope you can find a cause.

Regards, Edwin.

[schumaku]

Dear Edwin,
Suspect there are some misunderstandings what can be configured in the NFS access control fields - failures of providing the correct syntax can lead to access errors. Not nice; but true. Beyond, I understand; the QNAP syntax and options differ from what can be supplied to a common /etc/exports usage.

Allowed IP address or domain name
The format of the allowed IP address or domain name is shown below:
1. Single server: A valid domain name, host name or an IP address that can be identified by the DNS server.

I can't tell you, what the exact meaning of an IP address that can be identified by the DNS server is. Sorry my ignorance, have never tried with pure IP addresses - I'd have to ask somebody in Tw to run a test tomorrow, including the potentially "varying" (but risky) effects as you listed. As an old and lazy systems manager, I tend to use the much more flexible way of using DNS names (or NIS where available).

2. Use wildcard characters to specify a series of servers: Use “*” or “?” to specify the string criteria. When you use wildcard characters in a valid host name, dot (.) is not included in wildcard characters. For instance, when you enter *.example.com, one.example.com is counted while one.two.example.com is not counted.

The example (should...) make clear: There is no support for wildcards in IP network representations as seen below - only domain names can be used with * or ? wildcards - and a wildcard * does not make it span over multiple sub-domains.

3. IP network: Use a.b.c.d/z. a.b.c.d refers to the network and x refers to number of bits of the network mask, e.g. 192.168.0.0/24. Another valid format is a.b.c.d/network mask. In this case, a.b.c.d refers to the network and the following value refers to the network mask setting, e.g. 192.168.100.8/255.255.255.0.

This is the other config option, the old but not so lazy systems manager is using - as he has a well structured IP addressing and subnet scheme . You can give a try and specify a host as a subnet, using the xxx.xxx.xxx.xxx/32 or xxx.xxx.xxx.xxx/255.255.255.255 syntax.

4. Network group: Represented as @group-name; group-name refers to the name of NIS network group.

This only applies to NIS infrastructure where available.

Hope there is some light now.

Regards,
-Kurt.

[keys&sax]

Hallo Kurt,
Thanks for answering and giving more explanation.
This is what i did.

1. ...valid IP adress that can be identified by the name by the DNS...
Made a change to the a.b.c.d/255.255.255.0 format, it works and I will leave it there to so if it's still working after a few days.
[192.168.178.22/255.255.255.0, 192.168.178.25/255.255.255.0]
Did change one of the 6 allowed mounts to the IP of the modem/router [192.168.178.1/24] This also connects to the Qnap that is on 192.168.178.20, want to see if this one stays for more/less days than the other ones. (Is this a risk with internet?)

2. wildcards. its now clear to me that it is only intended for names.
Puzzle: just a [*] makes any mount possible. From the internet I have a port forwarding to Public. I don want to use this one because a have many personal files on the other entrances/folders

3. network masks. /24 also works for me. changed one of the mounts to this one to see what happens on the longer term.

4. NIS network groups in Ubuntu/linux are not familiar to me. It will be the weekend that I will do some reading on this.

From my response you can make up that for me it is like experimenting. If you have a strong answer on do's and dont's please let me know.

Regards / Grüsse
Edwin.

[keys&sax]

Hallo Kurt,
There it was again, now on the other PC where I have 3 mounts, all 3 failed at startup.

Started up and checked the other PC that has 6 mounts: all 6 were there.
Made an admin login on the Qnap.
Making now a "sudo mount -a" does not bring the connection.

Reply in terminal:
mount.nfs: access denied by server while mouting 192.168.178.20:/XOnly
mount.nfs: access denied by server while mouting 192.168.178.20:/Qdownload
mount.nfs: access denied by server while mouting 192.168.178.20:/Qmultimedia

In NFS access control the allowed IP adresses for the 3 mounts are (in folowing order):
192.168.178.22/255.255.255.0, 192.168.178.25/255.255.255.0 (computer adresses)
192.168.178.1/24 (modem/router adress)
192.168.178.22/255.255.255.0, 192.168.178.25/255.255.255.0 (computer adresses)

After making a change in the last one (from the long to the short alternative) and doing a "sudo mount -a" all 3 connections were back.
There are now 2 ways of bringing the mounts back: restarting the server or making a change in only one of the mounts of allowed IP adresses and giving a remount.

I was now having problems on dec 2, 4, 6, 9 and 11. Edit: and today 15 dec.
In the system connections log there are only statements with "Mount OK" on all dates.

What's happening and how can I make a stable and lasting NFS mount? Hope you can help.

Thanks, Edwin

Edit: making a change forward and back in one allowed IP connection just creates a kind off "reset" for all mountpoints. Shutting down and starting up the Qnap is the other way.
My 2 computers now make a kind of changeover of 2 till 3 days in not making mounts during startup, so it is about 4 till 6 days for the single computer.

[schumaku]

192.168.178.22/255.255.255.0 ... this is an eiter-host (the IP address) or a network (the mask 255.255.255.0)

192.168.178.22/255.255.255.255 -> this would be a host

Consider relaxing the NFS access list to one entry 192.168.178.0/255.255.255.0 to allow nfs mounts from all systems on the LAN on all shares - or remove te access list for a while, and test again.

In a way, I would like to have somebody from support cheking your NAS after a failure, and retring te mounts with your local help.

Regards,
-Kurt.

[corndog]

Hello all,

I am having very similar problems to this, and have done some looking in detail. I also use nfs on my TS509Pro from about 5 or 6 different Linux machines. They mount and dismount the volumes regularly. But After 3 to 6 days, NFS no longer works, and I have to reboot my QNAP, and then it works again for another 3 to 6 days. I have had my 509Pro for about 5 months now, and it has never once been up for 10 days. I always have to keep restarting it.

I have found that when I type a dmesg after the NFS problem happens, I see segfaults in the NFS service. So something is causing it to crash after running for a while.

This is very frustrating and a major problem for me in really trusting my QNAP with my data.

I have configured all my machines to mount with timeo=100,rsize=8192,wsize=8192 and just today I had another NFS crash and had to reboot my QNAP again - but it was after I tried to access it on NFS with a Linux machine that had been off for a while, and didn't have those custom options put in. So I can't tell if this fixes the problem yet.

Very frustrating - each time I have to wait several days to see if my latest attempt has fixed the problem.

BUT even if this fixes it, I shouldn't have to put custom settings like that in my linux computers. They all mount to my ReadyNAS 1100 just fine with no custom settings, and it has been running for over 400 days.

QNAP - Help!!!!

[keys&sax]

QNAP Kurt,

(Today the other computer failed, working with 255,255,255,255 is also no remedy.)

It's OK when someone of Qnap wants to check my Nas.
How to proceed? I can open up a port and can send a password to a private mail adress.

(Is it save? I'm not able to make backups of all the files stored.)

Regards, Edwin.

Edit 1: Timeout, I'am on holydays dec 21st until jan 5th.
Edit 2: Back from holydays there was no immediate reset needed, so it is not just a lineair timing problem.

Not alone in the dark anymore welcome Corndog

[corndog]

Hey keys,

Just a quick update - putting in manual settings for nfsmounts on the linux clients did not help at all. My 509 still has NFS completely dying after 2 to 6 days uptime. Only a reboot can fix it. I've tried everything I can think of and nothing has helped. still waiting for a fix from QNAP on this. Although I can imagine it will be tough for them to come up with one quickly, because each test takes several days to know if you've fixed anything.