itimpi

As far as I know no data is written to drives when starting the array in Maintenance mode.

If you have the Parity Check Tuning plugin installed then it this part of the additional information added to the history

What is ‘this’? No. It would be a parity sync. You can only do a parity-check if you already have parity. The rebuilt drive would have corrupt data on it.

Is disk1 showing as unmountable (which is what the diagnostics suggest)? If so the correct handling of unmountable disks is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

I have just pushed a new release that should fix the permission issues reported as introduced in the last release. In would welcome confirmation that this issue really IS fixed.

It I suspect that your issue is due to the fact that all the shares relating to docker and V/ms which you normally want only on the cache for performance have Use Cache=Yes set. That means you want mover to transfer the files from ca he to array if it can, and if you have files on the array then any writes to them will cause the parity dtive to be Aldo updated. BTW: the release of Unraid you are running (6.11.) has a bug so that we cannot see all the information about your shares - you should consider upgrading to the 6.12.5 release which is the current Stable version.

LT = LimeTech

@csrihari Thanks that shows that /user and some descendants has been reset. Not sure why I did not see the same on my system, but at least I know the package needs rebuilding to fix this.

I see entries like: Feb 10 20:08:43 NAS kernel: nvme nvme0: missing or invalid SUBNQN field. Feb 10 20:08:43 NAS kernel: nvme nvme1: missing or invalid SUBNQN field. Feb 10 20:08:43 NAS kernel: nvme nvme0: missing or invalid SUBNQN field. Feb 10 20:08:43 NAS kernel: nvme nvme1: missing or invalid SUBNQN field. And Feb 10 20:08:43 NAS kernel: nvme nvme1: globally duplicate IDs for nsid 1 Feb 10 20:08:43 NAS kernel: nvme nvme1: VID:DID 1dbe:5216 model:MKNSSDTS2TB-D8 firmware:2.0.0.14 In the syslog. maybe UD uses a different way of identifying the disks that Unraid itself does.

Yes, but when it happened that time I could see that the permissions had been changed. This time I cannot see any difference.

Not that I know of. Other similar scenarios a ‘quirk’ has been added to the Linux kernel. I believe it is deficiency in the drives firmware which stops them having unique id’s.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. there can be a problem if the drives do not report different serial information

You could if you use the option to use a custom schedule. You should look up the format of crontab entries to see how to do this.

There has been a report of this plugin breaking standard system permissions somewhere when it is installing? I cannot see this on my system so I would be grateful if someone who has this problem could post the output of a ls -l command at all levels of the path /usr/local/emhttp/plugins/dynamix/plugins. If there is an issue I would think it would most likely show up at the / or /usr levels.

NO! If you try that you will lose all your files you should read this section of the the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. It explains the role of the /mnt/user and /mnt/user0 mount points.

Just spotted that post. I have compared permissions on a server with the plugin installed and one without it and cannot spot any difference in permissions anywhere along the path it uses. I will have to wait and see if anyone else can pin it down further. I guess I could simply rebuild the plugin package and reissue it but that seems a bit pointless if I have not changed anything.

If this plugin is changing permissions during its install can you point me to where they are getting changed? That would mean there was mistake made when building the plugin that needs correcting and the plugin re-issuing. I checked on my system and I cannot spot any that have changed.

I notice for the ‘cache’ pool that you do have the Minimum Free Space setting as 0. You should set it to something larger than the largest file you expect to get added to stop it ever becoming completely full. I notice you do have this set non-zero for the other pool so maybe this just an oversight?

All we can see from the information you provided is that an Unraid shutdown was actively initiated - not what issued the shutdown command. you may get better feedback if you post your full system’s diagnostics zip file. You should also enable the syslog server so you can get logs that survive a reboot.

There is no -primary in a pool. If the drives have different performance, then the slowest drive becomes the limiting factor

The user shares probably disappeared because according to the syslog in the diagnostics the shfs process used to support User Shares had crashed.

The disks need to be formatted AFTER adding them to the array.

The 6.12 beta includes samba 4.17.4 which I think addresses these vulnerabilities?

I don’t know how you would end up with files in both locations unless there had been some manual action taken to cause this. That was why I asked about this.

Your syslog shows that many files on the cache seem to already exist on the array. Did you manually try moving files from the cache drive to an array drive at any point? I am asking as mover will not move a file from cache to array if that file already exists on the array. In Normal operation a file should only exist at one location - either on the cache or on the array - not both.