TerraMaster Forum

The passwords for the user list cannot be exported; this is not an exception.

TMzethar wrote: ↑20 Mar 2025, 18:53

I realise that.
Exporting the user list is not what caused the "exception"*. I cannot replicate it now as I am way beyond that stage, but it was importing the user list that gave an error - both without user passwords ( as list was produced) and with dummy passwords inserted as a test. The "exception" was shown for every user except the 2 users registered by default. [ie super-admin and guest] (Also note that the system was being updated and all the volumes, folders etc were unchanged from when the list was exported.

*I use the term "exception" guardedly since it was not used in the normal sense as it was not seen as a "kernel exception" or "system exception", merely a message in a dialogue.

We will continue to monitor this issue.

I went back to the device with the saved file system layouts and tried again (clearing conflicting user names that were added)
I finally realised that the issue was probably with formatting/file type of the spreadsheet list to be uploaded.
Initially I had examined the files using OpenOffice. This does not work directly with .xlsx files and I do not run Excel. This may have been the cause of the initial problems (Although the group files uploaded ok).
I then installed LibreOffice.
The copy of the user list first used appeared to be corrupted. I then tried anothe copy that Libre could read and display correctly.
I was able to manipulate the user list and, as a first step, removed all reference to the shared folders and permissions. So basically I was left with a plain list of users. For this test I inserted a password for each user (plain text).
The upload worked. Passwords were installed.
I then deleted those users again from the device and modified the user list to include all the previously deleted Shared folder data and permissions.
Upload appeared to work without the "exceptions" seen previously. However, the process seemed to hang. Possibly due to the large number of files needing to be updated (image repository), but I was curious to see what had happened, so refreshed the screen. It appears as if the process then terminated. Some shared folder permissions were implemented, others maybe not!
I can see at file level that some (not checked many) files (originally uploaded using ftp as a unique user name) are now owned by "sys". Other folders are now owned by "bin".

I will do some more verification but in the meantime suggest:
1) Improved verification of upload data format and user notification if incorrect (prior to proceeding).
2) Improved user notification of process status ('abort' option?) and/or time remaining estimate.
3) Investigate mechanism for simple 'user restore' of ownership (Folders and files)

Added to the discussion list.