I recently upgraded our relatively old QNAP TS-109 Pro NAS server to their newer TS-119P II model. Although I’ve encountered severe issues with Q-RAID 1 on the 119, I’ll cover that topic in another post. In this post I wanted to address a tweak to how our Ubuntu server is mounting NFS shares from the TS-119. Previously, the client’s /etc/fstab had entries along these lines:

However, I noticed recently that the wrong share for the NFS server would get mounted on the client. Getting the wrong share mapped to a local mountpoint really messed up the operation of apps on the client.

While I didn’t find this exact problem being discussed, I noticed that some people have been taking a slightly different approach to specifying the NFS shares:

4 Responses to “QNAP TS-119P II and NFS”

So, don’t leave us hanging. Tell us more about your issues with Q-RAID and the TS-119PII. I have one on order, and want to know what I’m getting myself into.

My primary motivator for updating was that I wanted to use Time Machine for a later model Macbook Pro, and the last revision of the TS-109P no longer supports Time Machine on later revisions of MacOS.

I’m also curious about the migration. From the QNAP site, It looks like it won’t work to do an in place migration (swap the disc into the new chassis – even with firmware update). Did you use remote replication?

Hah! It has been a major pain. Whenever I would attach an eSata drive and enable Q-RAID, it would get to xx% sync’d and then auto reboot. It would keep getting higher and higher percentage wise, but never reach 100% and become stable.

The same eSata drive worked fine for me with the old 109. So ordered a new 2 TB HDD to match the internal drive and experienced the same issue. Sigh.

QNAP said that my eSata drive caddy isn’t on their list of supported devices, but I even reverted to my old enclosure, but that didn’t address the issue.

QNAP is willing to pull the logs through a remote Team Viewer session, but it has been difficult to find the time during the business day to sync up with them. Maybe I’ll do it this week…

Interesting. I just did the forklift upgrade a few weeks ago, installing a parallel TS-119PII, a Thermaltake BlackX caddy and 3x WD red 2TB drives. I don’t see the issues you’re seeing, but after a while, after the initial sync completes, rsync seems to nearly always be running. Part of this may be that I set up TM backups for my work macbook, and it always seems to be changing bits, even if the change on the macbook is tiny.

I will say that the NFS support seems to be better. With the 109 our WDTV units had a hard time reliably seeing the NFS mounts. With the 119PII, it seems them reliably.

I’m kind of surprised that there are real, functional, differences between ESATA enclosures. I would have expected them to all be the same.

After several false starts in getting QNAP support involved, they told me a few weeks ago to wait for 3.8.2 to see if it would fix the issue. I applied 3.8.2 last night and saw that the darn thing rebooted itself four times over the course of 10+ hours as it was trying to complete the sync process. Fortunately, the sync finally finished with the “Q-RAID 1 initial syncing finished successfully.” entry in the log and the device seems to be stable.

The odd thing is that when this problem first started occurring, I let the NAS reboot multiple times as it kept getting closer to 100% sync completion. However, it wouldn’t get to 100% and I had to resort to disconnecting the eSata drive.

Since it now appears to be working fine, I am going to switch the HDD back to my raw drive caddy vs the older HDD enclosure to verify that it still works. I assume it will be OK.