TOS 4.1.28 is released for update

[TMSupport]

TOS 4.1.28 Release Notes

Applicable models:
ARM:
F2-210/F4-210
X.86:
F2-220/F2-420/F4-220/F4-420/F5-420
F2-221/F2-421/F4-221/F5-221/F5-421
F4-422/F5-422

This update includes following bug fixes for the previous version.
1. Fixed the issue of missing characters under admin menu;
2. Optimized the incorrect prompt message of Notification center;
3. Optimized the over high issue of CPU usage;
4. Fixed the no response issue after clicking “Click to view” at Notification center;
5. Fixed the failed downloading issue of TOS File Manager.


How to install TOS update?
1. Download the update package:
ARM: http://dl.terra-master.com/cn/TOS_A1.0_ ... 061659.bz2
X.86: http://dl.terra-master.com/cn/TOS_S2.0_ ... 061652.bz2
2. Go to TOS> Control Panel> General Settings> Update & Restore, and click “Manual Update”;
3. Click "Browse" to select the update package;
4. Click "Apply";

Issue report:
If you encounter issue during using, please report to TerraMaster official forum “TOS update”.

[Tricky]

One thing i have noticed but this apply's to both the old .27 update and the .28 is that despite having the time sync adjusted the same its always 3 mins behind my laptop time.

[michaels2408]

NFS mounting after reboot of TNAS is still an issue:

So I have tinkered with this quite a bit. I refreshed my whole TNAS back to a clean install of the new 4.1.27/28 firmware and still have the same issue as mentioned in other threads where NFS doesn't function correctly after reboot.

1. NFS daemon is now starting at boot as it should evidenced by the following:

[michael@vmserver ~]$ ssh root@192.168.1.80 -p 9222
Wellcom to TNAS
root@TNAS-010790:~# /etc/init.d/nfs status
nfsd is running
root@TNAS-010790:~#

2. NFS shares are not available even though daemon is running:

root@TNAS-010790:~# showmount -e
Hosts on TNAS-010790:
root@TNAS-010790:~#

michael@desktop:~$ showmount -e 192.168.1.80
Export list for 192.168.1.80:
michael@desktop:~$

3, Trying to mount a share provides a new error that does not show up much in google. Notice I tried to mount in verbose mode and get a one line response.

michael@desktop:~$ sudo mount -t nfs -v -o nfsvers=3 192.168.1.80:/mnt/md0/Pictures /home/michael/Pictures
[sudo] password for michael:
mount.nfs: access denied by server while mounting (null)

4. Going in to root@TNAS-010790 and running /etc/init.d/reload OR going into the TNAS TOS web page and unchecking the NFS tiick box hitting apply, the reselecting and applying fixes this issue. Now when I do the show mount:

root@TNAS-010790:/etc# showmount -e
Export list for TNAS-010790:
/mnt/md0/Documents *
/mnt/md0/Downloaded_Programs 192.168.*.*,*.home.intranet
/mnt/md0/Video 192.168.*.*,*.home.intranet
/mnt/md0/Pictures 192.168.1.0/24
/mnt/md0/Music 192.168.*.*,*.home.intranet,192.168.1.0/24
root@TNAS-010790:/etc#

michael@desktop:~$ showmount -e 192.168.1.80
Export list for 192.168.1.80:
/mnt/md0/Documents *
/mnt/md0/Downloaded_Programs 192.168.*.*,*.home.intranet
/mnt/md0/Video 192.168.*.*,*.home.intranet
/mnt/md0/Pictures 192.168.1.0/24
/mnt/md0/Music 192.168.*.*,*.home.intranet,192.168.1.0/24
michael@desktop:~$

And running mount will function as aspected:

root@TNAS-010790:/etc# /etc/init.d/nfs reload
Starting rpcbind: rpcbind: another rpcbind is already running. Aborting
FAIL
Starting NFS statd: Statd service already running!
FAIL
Starting NFS mountd: OK
Starting NFS daemon: root@TNAS-010790:/etc#

michael@desktop:~$ sudo mount -t nfs -v -o nfsvers=3 192.168.1.80:/mnt/md0/Documents /home/michael/Documents
mount.nfs: timeout set for Wed Jul 8 16:13:59 2020
mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.1.80'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.80 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.80 prog 100005 vers 3 prot UDP port 36700
mount.nfs: mount(2): Device or resource busy

Directory shows busy because it was already previously mounted as automount in the fstab file. If I select the directly it now will grant access to the NFS share on the TNAS

What I have found is that when the TNAS device restarts the NFS daemon starts up correctly, however the /etc/exports file is empty and the export data exists at /etc/exports.tmp
Moving exports.tmp to exports and re initiating with exportfs -a does nothing.

Please help. I am very tired and frustrated that the NFS function has not worked as expected, and I should not have to turn off the NFS and turn it back on in the TOS web app config panel evey time I reboot the TNAS device.

[TMSupport]

As we can't duplicate your issue here, so please send an email to support@terra-master.com with the detailed information, we would like to have a remote session for you to check what's going on there.

[Hardfecx]

There are some issues with the new update.
I disable the service "Bonjour" because I have no Mac but when i restart the nas, it is enabled again.

[jebll]

I also have an issue with the new update.
I disable the service "Telnet connection" (click apply) because I have no use for it and was previously told to disable to prevent 'mining', when i restart the nas, it is enabled again.

[Hardfecx]

I also have an issue with the new update.
I disable the service "Telnet connection" (click apply) because I have no use for it and was previously told to disable to prevent 'mining', when i restart the nas, it is enabled again.

same here with telnet

[michaels2408]

I have not heard back from customer support, however I resolved the NFS issue.
It appears the nfsd is starting too soon. So I created a new symlink ln -s /etc/init.d/nfs /etc/rc.d/S100nfs
Now when the TOS reboots the nfs service starts up at the very end, and all shares are accessible every reboot without any further intervention.

[TMroy]

Did you send email to support team and ask for a remote session? Anyway, I am happy to hear you resolved the issue. We will continue verify your issue. Thank you for all information you provided.

[michaels2408]

I sent the email to support several days back. It appears the system is calling and setting up the NFS server outside the system V init process, or possibly inside another init.d script. When I checked the /etc/rc.d dir there was not a sym link calling the /etc/init.d/nfs script at startup. So I created one. Originally I placed it at S97nfs, and it was still too soon. I had to make it the very last script called.