Environment: Main mail directory on separate ext4 data partition. Mint 19.2 XFCE, Claws 3.16.0, CPU AMD Phenom, ECC ram. Separate mail users are members of the same group. After running "sudo chmod -R g+s . " on the main Mail folder and doing a "ls -alrt" in the inbox, all files show as -rw-rwS--- . Good. Then, getting new mail from the server and doing "ls -alrt" again shows: rw-rwS--- 1 eri homeusers 19547 Jan 25 10:44 10672 drwxrwsr-x 21 root homeusers 4096 Jan 25 13:32 .. -rw-rw---- 1 mat homeusers 14142 Jan 25 13:38 10679 -rw-rw---- 1 mat homeusers 94765 Jan 25 13:38 10678 -rw-rw---- 1 mat homeusers 62815 Jan 25 13:38 10677 -rw-rw---- 1 mat homeusers 93579 Jan 25 13:38 10675 -rw------- 1 mat homeusers 82868 Jan 25 13:39 .claws_mark -rw------- 1 mat homeusers 4485424 Jan 25 13:39 .claws_cache -rw-rw-r-- 1 mat homeusers 16 Jan 25 13:39 .mh_sequences The . claws files do not honor the 660 chmod, and the 'S' does not appear on any modified files. I don't know what the difference is between a lower case 's' on the group (setgid) or the upper case 'S' . I also do not know if the s is relevant for files. If you then logout, login as another user of the same group, the new mails are not visible. If you then (with Claws not running) do a "sudo chmod g+rws .*" in that folder, and a "sudo chmod g+rws *" , then all entries show up with rws for the group, but a restarted Claws still does not see them.
Some more diagnostics: If, after the above, you log out (this unusually took > one minute, don't know why, Claws processing?) again, then log in again as the same user, and start Claws without getting new mails, go to the inbox, then Claws is processing for a short while and then older mails are visible, but now mails from later (13:38) on the same day are missing. The "ls -alrt" shows: -rw-rw---- 1 mat homeusers 78058 Jan 24 21:22 10779 -rw-rw---- 1 mat homeusers 11973 Jan 24 21:22 10781 -rw-rw---- 1 mat homeusers 3655 Jan 25 08:31 10783 -rw------- 1 mat homeusers 83020 Jan 25 08:57 .claws_mark -rw------- 1 mat homeusers 4489928 Jan 25 08:57 .claws_cache -rw-rw-r-- 1 mat homeusers 64 Jan 25 08:57 .mh_sequences Also, the files seems to have been renumbered, because the previous present file 10675 is not there anymore. Itself not important that a file name changes, but are the mh_sequences kept in sync? Because now it contains "unseen: 1-10788" which was not there before.
use the Folder(s) Properties option 'Folder chmod' and set it to 660.
(In reply to MatN from comment #1) The diffence between s and S relates to the execution bit. S -> execution bit is not set s -> execution bit is set
@Paul, chmod 660 _is_ set on ALL folders, I double checked. You told me for bug 4227. Besides, the dot files are not folders, so how can you influence that? I did not find a setting for it. @Michael, clear, thanks.
Oops, that was bug 4427, not 4227.
(In reply to MatN from comment #4) In that case, should the bug summary be "folder chmod doesn't affect .claws_mark and .claws_cache files" instead of "Mails on shared MH storage are invisible from other login"?
Hm, tecnhically you are right, that is the problem. But the user's effect is that they are invisible. If a future user searches bugzilla, the current summary tells more than some files which are not updated, don't you think?
Well, no. I see the bug tracker as a developer tool. The better the description (for the developer) the quicker the bug can be dealt with.
Created attachment 2167 [details] fix bug 4431 Try this patch.
My, that is quick! Is this against current git? Or 3.16 which I used? It will probably 24 hours before I can try that, very busy. Thanks, Mat
I did find a little time. Latest source I have is 3.17.8 downloaded 2020-12-27 . Patch went well, build also. I definitely solved that problem, and when switching between users it seems to be much quicker too when you open Claws and go to the inbox. Many thanks, excellent service! However, if all files have the rws bits set, and you received some new mails, the new files have only the rw bits set, not the s. Is this supposed to happen? If so, this bug can be closed. And, I still have a problem that even though the bits are now OK, there still is at least one directory where the original creator can see the messages, but another login cannot access it. (the original summary) The access rights look OK, for the directory they are drwxrwS--- . I´ll need to do find out more. If you think it is a completely different problem, this bug can be closed and I'll open a new one when I found out what it exactly is.
fixed in git