The SN code can only be found on the device's label, which is usually attached to the bottom of the device.
TOS 6.0.460 (X86) Beta is Released for Update
Re: TOS 6.0.460 (X86) Beta is Released for Update
To contact our team, please send email to following addresses, remember to replace (at) with @:
Technical team: support(at)terra-master.com (for technical support)
Service team: service(at)terra-master.com (for purchasing, return, replacement, RMA service)
Technical team: support(at)terra-master.com (for technical support)
Service team: service(at)terra-master.com (for purchasing, return, replacement, RMA service)
Re: TOS 6.0.460 (X86) Beta is Released for Update
I see that you quoted my conversation with DCCentR, but your question seems markedly different from DCCentR's.
Please include your forum ID and a link to this page in your e-mail or customer support window. This makes it easier for us to combine your comments from different contact channels.
Regarding the issue you mentioned, we have observed a similar phenomenon.
Could you try changing the hibernation mode from “no hibernation” to another option and see if it improves the situation?
To contact our team, please send email to following addresses, remember to replace (at) with @:
Technical team: support(at)terra-master.com (for technical support)
Service team: service(at)terra-master.com (for purchasing, return, replacement, RMA service)
Technical team: support(at)terra-master.com (for technical support)
Service team: service(at)terra-master.com (for purchasing, return, replacement, RMA service)
Re: TOS 6.0.460 (X86) Beta is Released for Update
Or on the box it came in
F5-221 TOS7.0.0777 - 4x4TB (Ironwolf) Traid
F2-424 TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (HGST) Traid
F2-221 TOS7.0.0777 - 1x3TB Ext4, 1x4TB Btrfs
F2-425+ TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (EXOS) Traid
F2-424 TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (HGST) Traid
F2-221 TOS7.0.0777 - 1x3TB Ext4, 1x4TB Btrfs
F2-425+ TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (EXOS) Traid
Re: TOS 6.0.460 (X86) Beta is Released for Update
FYI, I think they may have changed the format on later devices. My F2-424 does not seem to fit that numbering systemcrisisacting wrote: ↑04 Sep 2024, 21:43It's within the device's serial number. The first two numbers after the second hyphen is the year, the next two are the week. Yours would need to be 2025 or higher to not be effected by the limitation
F5-221 TOS7.0.0777 - 4x4TB (Ironwolf) Traid
F2-424 TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (HGST) Traid
F2-221 TOS7.0.0777 - 1x3TB Ext4, 1x4TB Btrfs
F2-425+ TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (EXOS) Traid
F2-424 TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (HGST) Traid
F2-221 TOS7.0.0777 - 1x3TB Ext4, 1x4TB Btrfs
F2-425+ TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (EXOS) Traid
Re: TOS 6.0.460 (X86) Beta is Released for Update
Yesterday, I updated from .420 to .460 and then immediately went to 461. Some weirdness happened: the PUID/GUID system seems to have completely changed, breaking some of my docker installs that were set up for specific users, and TOS folder permission settings not working as expected. I'll explain below, simplifying my setup. I wonder: has anyone else noticed similar?
Another NEW BUG NOTED: In File Manager, depending on the position where I right click to bring up the context menu, it gets positioned such that the bottom items (such as Properties and/or Reverse Select) are not visible/accessible, even when the window is moved to the top of the screen. This was not the case on 6.0.229
- My TNAS's shared storage drive is Volume2, and on it I have a shared folder called "Backups" and another shared folder called "PUBLIC". "PUBLIC" has subfolders called "Shared Audio", "Shared Movies", "Documents", and "Downloads". In addition to the SuperUser, I have created 3 other users - let's call them User1, User2, and Media. My goal is to create an environment where User1+User2 have full access to both the "Backups" shared folder and the "PUBLIC" shared folder while user Media only has access to "Shared Audio" and "Shared Movies" (and their subfolders).
- To do this, in the Control Panel's "Shared Folders" section, I put a checkmark in the "Replace the permissions of all subdirectories..." box on the General tab for both the Backups and PUBLIC folders, then granted full R/W permissions to User1+User2 for those folders while setting user Media to "Deny" so that at this point in time (temporarily is the intention), Media has no access to any shared folder. As I want user Media to only have access to "Shared Audio" and "Shared Movies" subfolders of "/PUBLIC" only, using TOS's File Manager, I then navigated to "Volume2/PUBLIC" and right click on "Shared Audio" folder and choose Properties. In Properties->Permissions, I check the box "Replaces the permissions of all subdirectories..." again and change user Media from "Deny" to "Read/Write". I repeated this procedure on the "Shared Movies" subfolder.
- My expectation is that my user Media will now be able to access the 2 subfolders I specifically granted it permission to access. However in testing (logging in using "Media" logon from my phone's file browser and then also after logging out of TOS6 and signing back in using Media logon, and using my KODI media centre to try to play back files it previously had no issue playing but finding it now throwing up an error and refusing to play), I discovered that user Media has full access to *nothing*. I rebooted the TNAS, no change. In other words, the manual change in user permissions I made to specific subfolders is not being respected... because the Shared Folder user permissions is overriding them; it should be the other way - individual folder/subfolder permissions should override the Shared Folder permission.
- As a workaround, I temporarily granted full permissions then checked some of my docker apps installed on my TNAS to make sure they were still working but no, so of them (the ones that I had set in the config/.env to use user Media) kept telling me "connection refused". It took me all evening to figure out why: since the TOS update, the PUID and GUID of my TNAS's user accounts has changed!! Whereas before, SuperUser was PUID:0/GUID:0 and User1 was 2:4 and User2 was 3:4 and Media was 5:4, now, after the update, running "cat /etc/passwd" command in Putty/SSH returns: SuperUser 0:0, User1 12:997, User2 14:997, Media 15:997; this means that I have to now check and/or update each Portainer/docker config with the new PUID & GUIDs if I want them to work.
Another NEW BUG NOTED: In File Manager, depending on the position where I right click to bring up the context menu, it gets positioned such that the bottom items (such as Properties and/or Reverse Select) are not visible/accessible, even when the window is moved to the top of the screen. This was not the case on 6.0.229
F2-424 w 1x 250GB WD SN580 Blue NVMe (TOS6.0.519) + 2x 4TB WD Red Plus 3.5"HDDs
Re: TOS 6.0.460 (X86) Beta is Released for Update
DanielB wrote: ↑13 Sep 2024, 18:49 Yesterday, I updated from .420 to .460 and then immediately went to 461. Some weirdness happened: the PUID/GUID system seems to have completely changed, breaking some of my docker installs that were set up for specific users, and TOS folder permission settings not working as expected. I'll explain below, simplifying my setup. I wonder: has anyone else noticed similar?
(Aside) A NEW BUG NOTED: in my phone's browser (MS Edge), when first logging in to TOS, the top toolbar does not display until I do a manual refresh of the page, every time.
- My TNAS's shared storage drive is Volume2, and on it I have a shared folder called "Backups" and another shared folder called "PUBLIC". "PUBLIC" has subfolders called "Shared Audio", "Shared Movies", "Documents", and "Downloads". In addition to the SuperUser, I have created 3 other users - let's call them User1, User2, and Media. My goal is to create an environment where User1+User2 have full access to both the "Backups" shared folder and the "PUBLIC" shared folder while user Media only has access to "Shared Audio" and "Shared Movies" (and their subfolders).
- To do this, in the Control Panel's "Shared Folders" section, I put a checkmark in the "Replace the permissions of all subdirectories..." box on the General tab for both the Backups and PUBLIC folders, then granted full R/W permissions to User1+User2 for those folders while setting user Media to "Deny" so that at this point in time (temporarily is the intention), Media has no access to any shared folder. As I want user Media to only have access to "Shared Audio" and "Shared Movies" subfolders of "/PUBLIC" only, using TOS's File Manager, I then navigated to "Volume2/PUBLIC" and right click on "Shared Audio" folder and choose Properties. In Properties->Permissions, I check the box "Replaces the permissions of all subdirectories..." again and change user Media from "Deny" to "Read/Write". I repeated this procedure on the "Shared Movies" subfolder.
- My expectation is that my user Media will now be able to access the 2 subfolders I specifically granted it permission to access. However in testing (logging in using "Media" logon from my phone's file browser and then also after logging out of TOS6 and signing back in using Media logon, and using my KODI media centre to try to play back files it previously had no issue playing but finding it now throwing up an error and refusing to play), I discovered that user Media has full access to *nothing*. I rebooted the TNAS, no change. In other words, the manual change in user permissions I made to specific subfolders is not being respected... because the Shared Folder user permissions is overriding them; it should be the other way - individual folder/subfolder permissions should override the Shared Folder permission.
- As a workaround, I temporarily granted full permissions then checked some of my docker apps installed on my TNAS to make sure they were still working but no, so of them (the ones that I had set in the config/.env to use user Media) kept telling me "connection refused". It took me all evening to figure out why: since the TOS update, the PUID and GUID of my TNAS's user accounts has changed!! Whereas before, SuperUser was PUID:0/GUID:0 and User1 was 2:4 and User2 was 3:4 and Media was 5:4, now, after the update, running "cat /etc/passwd" command in Putty/SSH returns: SuperUser 0:0, User1 12:997, User2 14:997, Media 15:997; this means that I have to now check and/or update each Portainer/docker config with the new PUID & GUIDs if I want them to work.
Another NEW BUG NOTED: In File Manager, depending on the position where I right click to bring up the context menu, it gets positioned such that the bottom items (such as Properties and/or Reverse Select) are not visible/accessible, even when the window is moved to the top of the screen. This was not the case on 6.0.229
Thank you very much for your valuable feedback. We highly value your user experience.
Regarding the concern about PUID/GUID changes after a system update, after careful investigation, we confirm that performing a system update directly will not trigger changes to these unique identifiers.
As for the issue with permissions not taking effect, we have recognized this as a key factor affecting user experience and have prioritized it in the optimization of the new version. Our technical team is working diligently to fully optimize the permission management feature to ensure that all settings take effect accurately. Please wait patiently for the release of the new version of TOS.
Regarding the abnormal display issue on mobile browsers, it may be related to compatibility with specific mobile models or browser versions.
As for the issue with the right-click menu position, this has been properly resolved in the new version.
Once again, thank you for your patience and support. We will continue our efforts to bring you better products and services.
To contact our team, please send email to following addresses, remember to replace (at) with @:
Technical team: support(at)terra-master.com(for technical support)
Service team: service(at)terra-master.com(for purchasing, return, replacement, RMA service)
Technical team: support(at)terra-master.com(for technical support)
Service team: service(at)terra-master.com(for purchasing, return, replacement, RMA service)
Re: TOS 6.0.460 (X86) Beta is Released for Update
I'm very desperate.
I LOST ALL MY DATA! ALL MY VOLUMES WERE FORMATTED WITHOUT ASKING ME.
I'M WRITING TO WARN YOU ABOUT THE NEXT UPDATE TO AVOID DATA LOSS, LIKE HAPPENED TO ME.
What I did:
- I was on TOS 6.0.461 on F4-424 with TRAID configuration with 4 disks and I checked that there were no TOS update.
- I took a system backup from the system configuration section
- I did a Factory Restore of the TOS from the system -> factory default menu because I needed to install the TOS to another disks.
- In the restore procedure I used the option to download the current version from cloud, as I already did other times
- I choosed 2 disks to install the TOS to
- At the first reboot after the installation, the system was stuck on GRUB and I need to shut it down manually and start it again
- The system booted regularly and I logged in.
- I did a system restore from the previously backup
- After the reboot I saw that all my shared folder from all the volumes vere disappeared and I found instead a folder with a strange name like 8VeBTHw83isk with inside another folder named @
- the used space of the volume1 was oly 2 gb instead of 3 TB
- I found that the TOS version now is 6.0.500
I didn't know if the problem was due to the upgrade to the new 6.0.500 version or the restore of the configuration because I didn't check my volumes soon after the reboot.
I asked the support but they said me that I need to contact some specialized company to get my data back from my disks.
Does Someone know some tools that I can use to try to get my data back? I don't want to spend hundred of Euros to get my data back.
Thanks for any support
I LOST ALL MY DATA! ALL MY VOLUMES WERE FORMATTED WITHOUT ASKING ME.
I'M WRITING TO WARN YOU ABOUT THE NEXT UPDATE TO AVOID DATA LOSS, LIKE HAPPENED TO ME.
What I did:
- I was on TOS 6.0.461 on F4-424 with TRAID configuration with 4 disks and I checked that there were no TOS update.
- I took a system backup from the system configuration section
- I did a Factory Restore of the TOS from the system -> factory default menu because I needed to install the TOS to another disks.
- In the restore procedure I used the option to download the current version from cloud, as I already did other times
- I choosed 2 disks to install the TOS to
- At the first reboot after the installation, the system was stuck on GRUB and I need to shut it down manually and start it again
- The system booted regularly and I logged in.
- I did a system restore from the previously backup
- After the reboot I saw that all my shared folder from all the volumes vere disappeared and I found instead a folder with a strange name like 8VeBTHw83isk with inside another folder named @
- the used space of the volume1 was oly 2 gb instead of 3 TB
- I found that the TOS version now is 6.0.500
I didn't know if the problem was due to the upgrade to the new 6.0.500 version or the restore of the configuration because I didn't check my volumes soon after the reboot.
I asked the support but they said me that I need to contact some specialized company to get my data back from my disks.
Does Someone know some tools that I can use to try to get my data back? I don't want to spend hundred of Euros to get my data back.
Thanks for any support
Re: TOS 6.0.460 (X86) Beta is Released for Update
I have not seen Tos6.0.500 yet so I cannot comment on this version.
Were these two new disks and not part of the array mentioned already?
Perhaps trying to install to 2 x nvme drives? and separate OS/data drives {which is not really possible yet}
If you were replacing 2 disks in the original array OR if you were adding 2 disks to the existing array, you would have needed to follow
one of the raid update/expand options which would automatically put the existing version of TOS on the disks.
If you really did have Traid on 4 disks, this is equivalent to raid 5 - 3disks data, 1disk parity - and you have the possibility of recovering
from a single disk failure. If you remove 2 disks you effectively break the array.
I believe that with TOS6.0.420 -> the usb boot/init drive is re-written with one effect being to automatically get the latest version from the servers
when doing a default install - looks like this is what happened. (Even if 6.0.500 has not yet been pushed to devices.) I don't think this is related to Tos 6.0.460 as per the subject of this post (or 461) just to the manner in which the install was performed.
In any case You might find some consumer software that could help you but that is a wild guess on my part since the Traid config is individual to TM.
{Please don't trust critical data to a BETA software product - at some point the probability of failure is highly likely}
I'm trying to understand this. You had 4-disk Traid array if I got that right?
Were these two new disks and not part of the array mentioned already?
Perhaps trying to install to 2 x nvme drives? and separate OS/data drives {which is not really possible yet}
If you were replacing 2 disks in the original array OR if you were adding 2 disks to the existing array, you would have needed to follow
one of the raid update/expand options which would automatically put the existing version of TOS on the disks.
If you really did have Traid on 4 disks, this is equivalent to raid 5 - 3disks data, 1disk parity - and you have the possibility of recovering
from a single disk failure. If you remove 2 disks you effectively break the array.
I believe that with TOS6.0.420 -> the usb boot/init drive is re-written with one effect being to automatically get the latest version from the servers
when doing a default install - looks like this is what happened. (Even if 6.0.500 has not yet been pushed to devices.) I don't think this is related to Tos 6.0.460 as per the subject of this post (or 461) just to the manner in which the install was performed.
In any case You might find some consumer software that could help you but that is a wild guess on my part since the Traid config is individual to TM.
{Please don't trust critical data to a BETA software product - at some point the probability of failure is highly likely}
F5-221 TOS7.0.0777 - 4x4TB (Ironwolf) Traid
F2-424 TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (HGST) Traid
F2-221 TOS7.0.0777 - 1x3TB Ext4, 1x4TB Btrfs
F2-425+ TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (EXOS) Traid
F2-424 TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (HGST) Traid
F2-221 TOS7.0.0777 - 1x3TB Ext4, 1x4TB Btrfs
F2-425+ TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (EXOS) Traid
Re: TOS 6.0.460 (X86) Beta is Released for Update
My situation is a TRAID with 4 disks. TOS was installed on HDD2 and HDD3. No TOS installed in nvme drives. I did not change or remove any disk , nor have I modified the RAID configuration.Gremlin wrote: ↑18 Sep 2024, 19:15 I have not seen Tos6.0.500 yet so I cannot comment on this version.
I'm trying to understand this. You had 4-disk Traid array if I got that right?
Were these two new disks and not part of the array mentioned already?
Perhaps trying to install to 2 x nvme drives? and separate OS/data drives {which is not really possible yet}
If you were replacing 2 disks in the original array OR if you were adding 2 disks to the existing array, you would have needed to follow
one of the raid update/expand options which would automatically put the existing version of TOS on the disks.
If you really did have Traid on 4 disks, this is equivalent to raid 5 - 3disks data, 1disk parity - and you have the possibility of recovering
from a single disk failure. If you remove 2 disks you effectively break the array.
I believe that with TOS6.0.420 -> the usb boot/init drive is re-written with one effect being to automatically get the latest version from the servers
when doing a default install - looks like this is what happened. (Even if 6.0.500 has not yet been pushed to devices.) I don't think this is related to Tos 6.0.460 as per the subject of this post (or 461) just to the manner in which the install was performed.
In any case You might find some consumer software that could help you but that is a wild guess on my part since the Traid config is individual to TM.
{Please don't trust critical data to a BETA software product - at some point the probability of failure is highly likely}
As mentioned in a previous post there's a problem with raid corruption involving IronWolf disks in resuming from sleep.
For this reason I wanted to install TOS on HDD3 and HDD4 (the 2 IronWolf disks already in the current raid) to prevent disk sleep and raid corruption.
The manner in which the install was performed is the same I already did and I just followed the wizard provided by TOS installer. I did not manipulate the RAID disks or perform any unusual actions during the installation. I simply reinstall TOS on different disks on the same raid.
I understand the risks of using beta software with critical data, but I upgraded to TOS 6 to search for potential solutions to the RAID corruption issue that I also encountered in TOS 5. My NAS was constantly in a synchronizing state, making it unusable.
Thanks
Re: TOS 6.0.460 (X86) Beta is Released for Update
F5-221 TOS7.0.0777 - 4x4TB (Ironwolf) Traid
F2-424 TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (HGST) Traid
F2-221 TOS7.0.0777 - 1x3TB Ext4, 1x4TB Btrfs
F2-425+ TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (EXOS) Traid
F2-424 TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (HGST) Traid
F2-221 TOS7.0.0777 - 1x3TB Ext4, 1x4TB Btrfs
F2-425+ TOS7.0.0777 - 2x500GB nvme (P3) Traid, 2x6TB HDD (EXOS) Traid



