Threaded Mode | Linear Mode

simoncn · (This post was last modified: 24-08-2019 12:12 by simoncn.)

Did you sync /share/Multimedia or /share/Multimedia/Music?

mccormw · 24-08-2019, 23:00

Tried another sync and did not get the dreaded 1000 owner - I am puzzled. But one thing is clear this is NOT an error in minimserver, it is something that QNAP has done.

simoncn · (This post was last modified: 24-08-2019 23:17 by simoncn.)

When you had the problem, did you sync all of /share/Multimedia or just /share/Multimedia/Music?

I understand that this isn't a MinimServer problem but I would like to understand exactly what is causing it and if possible reproduce it myself as it might be possible for me to change the code inside MinimServer to work around it.

mccormw · 25-08-2019, 10:54

No it was just Music, the other similar directories were synced separately to give smaller jobs, although Music is 1 TByte and only Films&TV is of any size. Some of these were OK and others had the dreaded 1000 owner. I am sorry Simon but I cannot think of anything being done differently.

simoncn · (This post was last modified: 25-08-2019 21:59 by simoncn.)

I have reproduced the strange "1000 everyone" ownership by doing the following. In your setup, the local NAS (see below) would be the 253be and the remote NAS would be the 412.

1) On the local NAS, create a regular user (not admin)
2) Login to the local NAS as this user
3) On the local NAS, create a folder containing files to sync to the remote NAS
4) On the local NAS, use HBS3 to do a one-way sync of this folder to the remote NAS
5) When the files arrive on the remote NAS, they have the "1000 everyone" ownership

So far, so good. Unfortunately, after doing this, I have not been able to reproduce the "Content directory error" message from MinimServer on the remote NAS.

Did you follow similar steps to the above?

mccormw · 26-08-2019, 08:12

Right
1) That would be user bill, ie me,
2) I assume you mean logging in via a workstation (Win10 in my case) not logging in to he NAS management screen, so Yes,
3) Yes but I cannot remember 100% how I did it. I think (about 90%) that I did it in Fie Station,
4) Yes
5) Snap

I also think I have discovered another problem in HBS3. If you create a backup to a remote server, in my case from the 253 to the 412 it kicks off a task on the 412 that creates the new backup directory. It gets the directory name from the job name. So if I create a job BillBakRemote on the 253 going to the 412 USB HD then on this disk it creates a directory BillBakRemote . But it doesn't kill the task which just sits there until the job is actually run and kills it when done. I think these open tasks cause problems when shutting down and as this is home system then I turn it off at night. I have also noticed that in the task list there appeared tasks with really weird names - a bit like those security codes MS used to use for Word etc - not attaching any significance here. Could these have been tasks where it lost its name etc?
I got a couple of more tests to do then I will send it to QNAP. Do you want me to report the "1000 everyone" dreaded error or do you mind doing that? Might be better for you as you seem to be more up on it than me.

mccormw · 26-08-2019, 08:32

Hmmm. Now I cannot replicate the problem. I have had an update off HBS3 in the last few days - I wonder.

simoncn · 26-08-2019, 10:41

(26-08-2019 08:12)mccormw Wrote: Do you want me to report the "1000 everyone" dreaded error or do you mind doing that? Might be better for you as you seem to be more up on it than me.

The "1000 everyone" ownership is not an error; it is just how Linux works when files are transferred to a system that doesn't have a username matching the username that was used to create the files. In your case, the files were created on the 253 using the username bill. The username bill corresponds to the user number 1000 on the 253 and Linux puts the user number 1000 in the files. The files are then transferred to the 412 where no username bill is defined, so Linux shows the user number 1000 instead.

The error (which neither of us can reproduce now) is that somehow the path /share/Multimedia/Music ended up as not being valid on the 412 after running the sync job. This probably has something to do with ownership or permissions but I can't pin it down in more detail at present. Following up on your comment about unfinished jobs, I wonder whether the 412 was powered off during a sync job and this somehow left the /share/Multimedia link on the 412 in a bad state. This is just a guess with no evidence and I think we would need a repeatable scenario before we could submit a problem report to QNAP.

mccormw · 26-08-2019, 13:04

Yup I agree Simon. btw user bill does exist on both and is a member of the admin group on both.
HBS3 is newly released and looking at the forums it does have a few bugs and some nasty and cruel things are said about it. I am a retired programmer, I used to work in the commercial (I guess you'd call it) environment. My customer base was Investment Banks and Insurance Companies in the main and I know how bloody hurtful it is when someone rubbishes your software.

simoncn · 26-08-2019, 14:30

(26-08-2019 13:04)mccormw Wrote: Yup I agree Simon. btw user bill does exist on both and is a member of the admin group on both.

My test was with the other user as a member of the everyone group but not a member of the admin group. Is your user bill a member of both the everyone group and the admin group on both machines?