HTTP Share not working correctly

[bidmead]

BTW...

> The workaround to 1. is to run TOS admin using tnas.link. If you're not accessing the NAS locally you'll get a tnas.link URL when you share a file from the NAS. This is useable but it isn't the way other NAS operating system handle this.

I've missed something out here. This will only work if you're accessing the tnas.link login through a VPN or are in some other way outside the LAN. Otherwise, the URL simply reverts to a LAN address. I routinely use a VPN, so I hadn't noticed this until testing on another system.

And the function of the Flash the recipient receives seems to be to play the multimedia file. This function could very easily simply be removed, being restored in HTML5 in due course.

--
Chris

[bidmead]

Thank you for your suggestion, Chris. We will consider adding it into our revision plan.

Dare I suggest that the problem is too important for you simply to "consider adding it" to the revision plan. This F2-210 (the example I have here) is a fine piece of hardware at a very competitive price. It doesn't deserve to be still depending on deprecated 1990s software.

Adding the option of a workable WAN address based on the TNAS ID to the current LAN address for shared files is a no-brainer. Work on this should be trivial and I would expect an update within days. The conversion of the Flash in-browser player to HTML5 is no less complex and should have been in place well before the Flash EOL at the beginning of this year.

I'm finding it hard to tell you how astonished I am that a nation so evidently adept at creating superb hardware and software is letting this lie fallow. And that now I've returned to this forum a month later we are still having to edit the shared URLs by hand and fudge around to avoid spurious Flash error messages.

(The fudge is rather simple, though. Rename any multimedia file (eg mysong.mp3=>mysong.mp3.x) so that the browser won't recognise it as playable and so won't attempt to trigger Flash.)

–
Chris

[bidmead]

I've run into a new problem with TerraMaster file sharing. When I send a tnas.link link to a directory (rather than an individual file) the recipient's browser shows the open directory with all its files rather than an icon of the containing folder.

This wouldn't be a big deal if the Select All and Download buttons actually worked. Select All does indeed select all the files in the directory but the download button just says "Download Starting" and doesn't do anything else. Would I be right in thinking that TerraMaster is still relying on Flash in trying to drive this?

Manually selecting all the files in the test case I'm using (a couple of dozen) and then using the context menu Download does get something moving. The files begin to be zipped (it seems) but then… nothing.

This mechanism sort of works in that I can download a pair of selected files successfully. So it seems that the zip process is timing out.

It would be helpful it others in this forum could test this and give me a sanity check.

Meanwhile, the workaround is not to attempt to share directories but to zip them into a single file first.

–
Chris

[RyanYang]

{L_BUTTON_AT}bidmead

Hi,
Click select all and then click download to compress it, and the compression time will be a little longer when there are many files.
We will verify whether the compression speed during sharing is normal.

[bidmead]

Thanks for that swift response, @TMRyan. Yes, I had tried your suggestion and have been unable to get it to work. Here are my findings.

To test tnas.link URLs over my LAN it's necessary for me to use a VPN (Windscribe). Without this, all tnas.link URLs are translated back into LAN URLs. I am attempting to download a directory of around 30 MP3 tracks, averaging around 12MB each.

When I Select All and Download I get three pop-ups, almost simultaneously. "Download will automatically begin…", "Download starting" and "Operation successful". However, no download is happening or has happened.

When I select fewer files, say four, I see the "Download will automatically begin…" message and there is evidently an attempt in progress to zip these four files. But this message is soon replaced by a red "System error" pop-up and I get a large ajax error message from Windscribe that it has lost contact with the tnas.link address.

This all seems to point to a timeout failure with TerraMaster's zipping process but if you can suggest another cause I'll be happy to look into it for you.

Meanwhile, I'm roping in some colleagues to sanity check this remotely without the necessary Windscribe intervention. Feedback from them so far suggests that the Select All Download procedure you've suggested fails for them too.

It would be very helpful if others in this forum could pitch in and test this as well. The more data we have, the easier the diagnosis should be and (hopefully) the faster the fix should arrive. As I've already reported here, the only workaround I've been able to come up with has been locally to zip any directory BEFORE deriving a tnas.link URL.

–
Chris

[bidmead]

Further experiment suggests that it the BYTE SIZE of the bundle to be zipped rather than the NUMBER of files to be zipped that is the boundary condition.

I've managed to download a zip of four small files (total zip size 6KB) but a download attempt of four files of around 12MB each fails as previously reported.

–
Chris

[TMS]

Thank you for your inform, we will test and verify it.

[bidmead]

Many thanks. I've since had confirmation of the multiple download problem from a colleague accessing our review sample F2-210 remotely without a VPN. The WebUI auto-zipping into a small zip file works but attempts to auto-zip and download a larger haul fail as described in my previous report here.

The same colleague has also raised the question of how to upload to a remote TerraMaster NAS. It seems that attaching to (say) Windows File Explorer using the tnas.link connection via Samba is a no-go and the TerraMaster WebUI doesn't seem to offer drag-n-drop or file upload facilities (unless I'm missing something, which is not unlikely).

Can you give any advice on this?

–
Chris

[bidmead]

Apologies, that previous post is now uneditable, otherwise I would have added this follow-up there.

The answer is to create a Shared Folder (TOS Desktop> Control Panel> Privileges> Shared Folder) with appropriate permissions. It should then be accessible for uploads using the left-hand button (marked "Upload" that appears above the folders file list.

–
Chris

[TMS]

Hi，
1. If the size of the folder is too large, an error will occur during the compression process and the download will not be possible. We are fixing this feature.
2. WebUI drag-n-drop is not ready yet, it is still under development and testing.