MrChip

I've solved my remaining problems. The error on setresgid was because te user data I had been using was now forcing the container to try to change its guid. I had specified a setting for a specific mail group id, but in the container environment, that setting doesn't work because the container process runs without sufficient privileges. I also had to change the user gid for my user account on dovecot, again to avoid forcing a gid change the process didn't have the permissions to do. After that, my thunderbird client was able to login. I had some trouble getting the thunderbird client to list all the folders. I wound up going through a process to import my previous Maildir folder tree into the new container tree, and then resubscribe all the folders in thunderbird. Now I can see the full tree through the thunderbird client. I hope this blurb may help someone else who might hit the same issues on upgrading their Dovecot docker container.

Thanks, that was helpful. It revealed where they had made changes to the container that I had to account for in my config files.

So I've made progress. They changed the docker quite a bit at v2.4, and I had to change the port mappings and the path mappings to align with the new container set-up. Getting the configuration path mapping corrected got me past the "user doesn't exist" error. I next had to solve a login issue where my dovecot user wasn't getting authenticated. I resolved that issue , again by finding the changes made in configuration settings with respect to password file location and password encryption settings. I think I'm almost there. my current problem is a permission error showing up in the log: Fatal: setresgid(100(users),100(users),8(mail)) failed with euid=1000(vmail): Operation not permitted This may be a conflicting UID issue. The container seems to be using UID 1000 for a process it runs, but my dovecot user also is UID 1000 (and GID 100), so there may be some collision there. I'm not sure the easiest way to confirm or handle that - all the existing mail files and folders are owned by UID 1000,

Hi. I've been working on upgrading my Dovecot docker to the latest version 2.4.0. There were a lot of config changes I had to make to make 2.4.0 happy. I've got though all the config file errors and now the container is throwing: doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf: default_login_user doesn't exist: dovenull I've been using this container for years as local archive storage for email worth keeping. I have a file named "etcp" in my config directory that is in the passwd format and it has the referenced dovenull user, but it seems that the container is no longer using it. I don't recall having to do anything specific with that "etcp" file in the past, but it's been so long since I set it up, that I've forgotten that detail. I think that I should be getting that "etcp" file moved into the docker's space as it's passwd file. But I'm not geting how to accomplish that. I tried setting up a mapping from //etc/passwd to my "etcp" file (which wasn't in my config before this upgrade, and things worked), but I get permission errors on the log file in var/log, so that doesn't appear to have been the right thing to try. Has anyone got through the dovecot docker upgrade. Can you suggest what I need to try next? I'm not strong on docker so perhaps I'm missing something in docker configuraiton. Any help is appreciated. Thank you.

If anyone is interested in why this error happens in the first place, it's because (I believe) the file system on /boot is vfat. The ssh command wants to update the known_hosts file and it tries to make a backup copy of known_hosts using the link command ln. But it's trying to make a hard link, and hard links aren't supported on vfat file systems. So the operation isn't permitted. By running the ssh-keyscan and adding its output to known_hosts, ssh is happy with the content of known_hosts and doesn't need to update it, so the error is avoided.

I recently upgraded to 6.12, and I'm now at 6.12.6 on 3 servers. I'm seeing these log messages repeating over and over on 2 of the servers. Jan 4 13:56:08 bailey-un monitor: Stop running nchan processes The TLDR version: I see the nchan log messages repeating over and over on one server after the client PC goes to sleep and the browser there stops accessing the web GUI without logging out. This has happened on a second server but I can't confirm at this time whether it happened again today. I'll have to confirm that later when the server is accessible again. Today, it did not occur on a third server - just one message there. In detail: On the server shown here, the message repeats every 33 seconds. Jan 4 13:56:08 bailey-un monitor: Stop running nchan processes Jan 4 13:56:41 bailey-un monitor: Stop running nchan processes Jan 4 13:57:14 bailey-un monitor: Stop running nchan processes Jan 4 13:57:47 bailey-un monitor: Stop running nchan processes Jan 4 13:58:20 bailey-un monitor: Stop running nchan processes Jan 4 13:58:54 bailey-un monitor: Stop running nchan processes Jan 4 13:59:27 bailey-un monitor: Stop running nchan processes Jan 4 14:00:00 bailey-un monitor: Stop running nchan processes Jan 4 14:00:33 bailey-un monitor: Stop running nchan processes I've seen an earlier thread (https://forums.unraid.net/topic/144710-since-6124-monitor-stop-running-nchan-processes) but it didn't seem to come to a resolution for what I'm experiencing. These messages start after the client PC is put to sleep. I didn't close the browser tab or log out of the session - I just put the PC to sleep. There should be no further activity from the browser session on that PC until it wakes up again. But these messages keep being generated over and over. The messages stopped when a new GUI session to the server was opened from a different client PC on a different local subnet. Jan 4 20:35:41 bailey-un monitor: Stop running nchan processes Jan 4 20:36:14 bailey-un monitor: Stop running nchan processes Jan 4 20:36:47 bailey-un monitor: Stop running nchan processes Jan 4 20:36:55 bailey-un webGUI: Successful login user root from 192.168.x.y Jan 4 20:36:58 bailey-un emhttpd: WDC_WD10EZRX-00A8LB0_WD-WCC1U2905249 (sdg) 512 1953525168 Jan 4 20:36:58 bailey-un emhttpd: read SMART /dev/sdg (This is the end of the log and was copied at 21:06 local time, so there's nothing in the log after 20:36:58.) One of my servers didn't get into this state today. I recorded a single instance of the log message when the client PC (same client PC as above) went to sleep. Jan 4 13:46:29 flint-un emhttpd: spinning down /dev/sdb Jan 4 13:55:43 flint-un monitor: Stop running nchan processes My third server has shown the repeating nchan log messages in recent days, but it is currently in accessible and likely down. (I'm not there to investigate it further right now so I can't say if it started these messages today or not. The same client PC was connected there too.) I think that the repeating messages are a bug - a single message makes sense when the client PC goes to sleep, but repeating messages don't make sense as the client is now silent. Your thoughts?

After replacing disk1 and rebuilding the parity, and waiting for several parity check cycles, I conclude that my parity errors reported in the OP were due to a failing hard drive. Since replacing the drive I have no parity errors reported over multiple parity checks. I consider this issue to be resolved.

Disk1 has now failed (several days ago now). A file system check showed tons of errors, and the root of the file system was unreadable. I took disk1 out of the array so the array had just disk2 and parity. I rebuilt the parity and restored the data from backup. I've run several parity checks since then and all are zero errors. I bought a new disk, zeroed it, and added it to the array today. A parity-sync is in progress. I'll run a parity check daily for a time to keep an eye on it. I think disk1 was the source of the parity error that prompted my OP, but I'll wait a few parity check cycles before I conclude that. I want to thank JorgeB for his input and suggestions - much appreciated.

Hmm, I just found these logs on the disk log for the parity drive. It shows wsdd is failing at times - segfault and general protection fault. I see them only in the disk log for the parity drive, not the other drives. I'm not sure if they are significant to my parity correction problem or not. Oh, and they do also appear in the syslog (but a fewer number - I mean that there are more wsdd segfaults in the parity drive syslog then in the syslog over the same time period. Here's what appears in the parity drive log: Aug 17 11:15:33 chip-un kernel: sd 7:0:0:0: [sdd] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB) Aug 17 11:15:33 chip-un kernel: sd 7:0:0:0: [sdd] 4096-byte physical blocks Aug 17 11:15:33 chip-un kernel: sd 7:0:0:0: [sdd] Write Protect is off Aug 17 11:15:33 chip-un kernel: sd 7:0:0:0: [sdd] Mode Sense: 7f 00 10 08 Aug 17 11:15:33 chip-un kernel: sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA Aug 17 11:15:33 chip-un kernel: sdd: sdd1 Aug 17 11:15:33 chip-un kernel: sd 7:0:0:0: [sdd] Attached SCSI disk Aug 17 11:18:35 chip-un emhttpd: ST2000DM008-2FR102_ZK303HMX (sdd) 512 3907029168 Aug 17 11:18:35 chip-un kernel: mdcmd (1): import 0 sdd 64 1953514552 0 ST2000DM008-2FR102_ZK303HMX Aug 17 11:18:35 chip-un kernel: md: import disk0: (sdd) ST2000DM008-2FR102_ZK303HMX size: 1953514552 Aug 17 11:18:35 chip-un emhttpd: read SMART /dev/sdd Aug 17 11:18:38 chip-un root: /usr/sbin/wsdd Aug 17 11:24:21 chip-un root: /usr/sbin/wsdd Aug 17 11:24:23 chip-un kernel: wsdd[16602]: segfault at 1004d ip 0000000000403c92 sp 00007fffcd51c250 error 4 in wsdd[402000+4000] Aug 18 13:19:13 chip-un emhttpd: read SMART /dev/sdd Aug 18 13:19:55 chip-un root: /usr/sbin/wsdd Aug 18 13:43:37 chip-un emhttpd: read SMART /dev/sdd Aug 18 13:43:39 chip-un root: /usr/sbin/wsdd Aug 18 13:44:01 chip-un root: /usr/sbin/wsdd Aug 18 13:44:03 chip-un kernel: wsdd[14070]: segfault at f0007624 ip 0000000000403c92 sp 00007ffe41a216b0 error 4 in wsdd[402000+4000] Aug 18 13:44:08 chip-un root: /usr/sbin/wsdd Aug 18 13:44:08 chip-un wsdd[15554]: set_multicast: Failed to set IPv4 multicast Aug 18 13:44:08 chip-un wsdd[15554]: Failed to add multicast for WSDD: Address already in use Aug 18 13:44:08 chip-un wsdd[15554]: set_multicast: Failed to set IPv4 multicast Aug 18 18:48:28 chip-un emhttpd: read SMART /dev/sdd Aug 18 18:49:09 chip-un root: /usr/sbin/wsdd Aug 18 18:51:06 chip-un emhttpd: read SMART /dev/sdd Aug 18 18:51:06 chip-un root: /usr/sbin/wsdd Aug 18 18:51:27 chip-un root: /usr/sbin/wsdd Aug 18 18:51:29 chip-un kernel: wsdd[28652]: segfault at e08ade5f ip 0000000000403c92 sp 00007ffea454b4a0 error 4 in wsdd[402000+4000] Aug 18 22:29:04 chip-un emhttpd: read SMART /dev/sdd Aug 18 22:29:25 chip-un root: /usr/sbin/wsdd Aug 18 22:31:45 chip-un emhttpd: read SMART /dev/sdd Aug 18 22:31:46 chip-un root: /usr/sbin/wsdd Aug 18 22:32:07 chip-un root: /usr/sbin/wsdd Aug 18 22:32:09 chip-un kernel: traps: wsdd[19417] general protection fault ip:403c92 sp:7fff4f11f7c0 error:0 in wsdd[402000+4000]

I'm glad I'm well backed up ... I've put the array into maintenance mode and performed file system check (through the GUI). There were a lot of issues that were fixed. I restored affected files from backup. All disks pass a file system check fine now. I brought the array online normally and did a parity check (with correction). Over 16k corrections, but I guess that may not be a big surprise given the file system damage that had occurred. I did a second parity check right after the first one. It'll finish in a few minutes, but it's already over 17k corrections. That's way out of whack. I'm not sure how to approach this issue from here. JorgeB suggested a memory issue, but my feeling is that if a memory issue was creating that many parity corrections that there would be other signs and symptoms in the system.

Thanks. I'm now getting file system errors on disk1: root@chip-un:~# cd /mnt/disk1 root@chip-un:/mnt/disk1# ls ./User/kntc/Accounting /bin/ls: cannot access './User/kntc/Accounting': Structure needs cleaning root@chip-un:/mnt/disk1# I'm starting another thread to ask about fixing a file system on an Unraid array. Edit: there's plenty of posts/info about fixing filesystem issues, so I didn't start a new post. It's not likely a coincidence having the parity errors and the file system errors. But the cause isn't clear. I'm leaning to disk or controller, but memory is still possible too.

One thought I've had is to take disk2 out of the array and then check parity on just disk1 for a few days. If the parity errors cease, then disk 2 is suspect. Otherwise disk1 or parity is suspect. Could the disk controller be a source of these issues? I have these disks on an LBA.

I've been watching the server more carefully today, and things have changed quite a bit from the OP. In the OP the Raw_Read_Error_Rate was 79448/79456/183312320 (parity/disk1/disk2). Today I have: root@chip-un:~# smartctl -a -v 1,raw48 /dev/sdd | grep Raw_Read 1 Raw_Read_Error_Rate 0x000f 082 064 006 Pre-fail Always - 165959888 root@chip-un:~# smartctl -a -v 1,raw48 /dev/sde | grep Raw_Read 1 Raw_Read_Error_Rate 0x000f 082 064 006 Pre-fail Always - 168463584 root@chip-un:~# smartctl -a -v 1,raw48 /dev/sdf | grep Raw_Read 1 Raw_Read_Error_Rate 0x000f 082 064 006 Pre-fail Always - 173822392 root@chip-un:~# (sdd=parity, sde=disk1, sdf=disk2) Quite the big change for parity and disk1, but now they are in the same ballpark with disk2. So I'm no longer thinking that disk2 is the most likely culprit. I did another parity check today - 1516 parity errors this time. Today I did not write corrections to parity, but last time I did. I'm not sure which way to go on this question. If one of my data drives is failing, could writing parity mess things up even further?

Okay, that's helping me understand the numbers. Thanks. So using the smartctl command suggested I see an error count of 0 for all 3 disks. But now I'm still wondering why the figure for disk 2 is so much higher than the other two disks. For (parity/disk1/disk2) the Raw_Read_Error_Rate was (in the OP) (79448/79456/183312320). If I understand, since the error count is 0 for all three, then these numbers are the number of reads/seeks. I don't understand the difference across the three disks. If the values for the parity disk and disk1 are sensible, the the value of 183312320 for disk2 doesn't make sense as that disk is essentially empty. And all 3 disks were bought at the same time to populate this server - their Power_On_Hours is (21736/21752/21710), so disk2 isn't any older. Disk2 should have less reads/seeks, not several orders of magnitude more. Or maybe the parity and disk1 figures are too low for Raw_Read_Error_Rate? Only 79k after years of service and plenty of parity checks?

Thanks for the input, but what's the number 2 suspect? I ran Memtest86 (10.5) - 4 passes, 5 hours and 8 minutes elapsed time - and there were zero errors. What's the way to read the Seagate drive figures? All 3 drives are Seagate and bought at the same time, but just one has the error rate in the millions. The other two are in the 74000 range. I'm again thinking that disk 2 has issues.