carlel

Awesome I will look into this thanks!

I can't control the clients though, they may be using files during a power down event. Can SMB not be forced to shutdown?

It may not be all, but it is most shutdowns. It seems to be an issue with samba mounts. I have a few windows systems that map shares as network drives. If I remote into those systems and dismount all shares, that seems to fix it. I don't see any open files when I check with smb tools on unraid though.

There are many threads about getting stuck during array with an error "retry unmounting share". The suggested typically is to go force unmount things or disconnect network shares. That's inconvenient but workable in most situations, and I've run into it myself several times. However, I've just had an incident where the power went out, and the UPS triggered shutdown. The shutdown never completed because of this issue. Luckily the power came back up before the UPS died. Side note, the shutdown did eventually finish. I'll still leave UPS shutdown enabled because a chance is better than nothing, but without any ability to force the array to shutdown its reliability is limited. Is there no way to force clients offline, or otherwise force the array to shutdown in necessary situations like this?

I should add that the Vim issues I was seeing are apparently a problem between Vim and Samba; (Suppress/bypass "file has changed" errors when editing cifs/Samba files). That leaves the only unexplained issue as the media file corruption, which hasn't yet reoccurred. A few more dockers are running now and in addition to the manual MD5 indexes I've built I'm running Dynamix File Integrity to help keep an eye on it.

With new memory installed I recopied all the data then logged and compared an md5 on each file against the original. No corruption yet. Today I turned docker back on and am slowly re-enabling containers one at a time. I'll keep validating MD5 as I turn containers back on. I still wonder if some bad configuration could have caused this but I'm not sure I'm interested in taking a chance on putting the old RAM back in. I'll update back here if anything changes. Thanks again.

Thanks for the analysis. It is ECC; that and memtest had me thinking the ram was OK. I have two fully new RAM chips coming this week I will test with. I can't run just one chip because minimum 1/processor is required (I think). Are there any diags I can run to rule the cpu(s) out?

The short question is - why did this happen? I found instructions to fix it with xfs_repair (I'll have to use -L) but how can I prevent this from happening again? Does this indicate an issue with the drive, or just the filesystem? The longer version... I'm weeks into this hardware migration and I'm at my wits end. All the troubleshooting steps take days to run and are inconclusive. I've migrated to new hardware (used 730xd) with my old drives (2x2TB) and added four new ones (4x12TB refurbished, from two different sources). All 4 new drives were precleared and tested. I began migrating files from windows drivepool (over samba) with Teracopy. Teracopy validation passed. Later I noticed issues with some files. VLC gave index errors for AVI files. Media files would play, but not to the end. File sizes were correct, but MD5 on source/destination was now different. I tried again with rsync. The results were the same - rsync did not report any errors, but afterwards MD5 did not match. I posted on the forums and got a recommendation to run memtest, which I did over a weekend. No errors. I tried a few other things (creating single disk shares to try to isolate the issue to a specific drive) but those have been inconclusive, mostly because I started to get lost with which files had been tested. The majority of files had been assigned to disk2, so I set the share to exclude disk2 and copied a large subset of files. I spot checked files with manual MD5 as the copy was in progress and they were all fine. The copy finished yesterday and today I was getting ready to run the batch MD5 on all files. Sometime this morning I got the corruption error. One more odd thing I noticed right before this... I was using gvim to edit a file on the share, over samba. I would make some changes, save the file, make some more changes ... and when I went to save again, vim warned me the file had changed on disk. If I reloaded the file I would find that my last change had not actually been saved. Any insight or suggestions on any of this would be greatly appreciated. Thanks, C tangerine-diagnostics-20240724-0954.zip

Awesome, thanks. I'm surprised they weren't fixed at reboot or by fix permissions... unless something else is messing with them. I'll have to reboot again and see if the fixed perms stay.

What are the correct permissions for /mnt/user? I've fixed my issue by setting a+x on '/mnt/user' but want to check what it's supposed to be. I started being unable to connect to any smb shares; getting a "chdir_current_service: vfs_ChDir(/mnt/user/test) failed: Permission denied." error. Docker and VM are shutdown. I rebooted multiple times and ran fix permissions and dockersafe fix permissions. My user folder was: drwx------ 1 999 users 296 Jul 17 08:35 user/ Now changed to this and I can connect with SMB again. drwx--x--x 1 999 users 296 Jul 17 08:35 user/

I ran 4 passes... no errors from memtest. Now I have to put this issue on hold to figure out why I can no longer connect to SMB shares. "chdir_current_service: vfs_ChDir(/mnt/user/test) failed: Permission denied. Current token: uid=1000, gid=100, 4 groups: 100 3003 3004 3006".

Oh bummer, well thanks for the information. I"ll run memtest on it tonight.

I have been migrating data off my old drivepool server; first using rsync and then using teracopy. With both methods I found that even though they passed checksum validation, after copying if I ran md5sum on unraid files would be wrong. I disabled all of docker and it believe it's been fixed. I found two bad mappings.... Unmanic had its cache mounted to /mnt/cache instead of /mnt/user/appdata (which has primary storage of cache). Postgresql had database storage mounted to /mnt/disk1/appdata/postgresql13 instead of /mnt/appdata/postgresql13. I know that writes between shares and disks is bad, and my cache is btrfs. Can someone confirm (or deny) that this is a likely culprit? I'm going one directory at a time now and validating each one, but would like a second opinion to help me rest easy or keep looking for a culprit. Thanks, C

2024/06/19 14:35:32 [emerg] 6457#6457: a duplicate default server for 0.0.0.0:80 in /etc/nginx/conf.d/servers.conf:60 2024/06/19 14:35:32 [emerg] 6460#6460: a duplicate default server for 0.0.0.0:80 in /etc/nginx/conf.d/servers.conf:60 I was getting the above in /var/log/nginx/errors.log so I checked the config and commented out the second server block, then used /etc/rc.d/rc.nginx restart to restart nginx. This got the UI up again.

Is it possible to restart the UI from the command line? I'd prefer to avoid restarting. Is this indicative of any issues? Any logs I should check before rebooting? Thanks.