Hi Tobias and Richard. Thank you for answering my questions. I got the link suggested by Tobias on the issue report, which led me to further investigation. It was hard to see what version the kernel version on the system was using, but looking at the result of "ceph health detail" and ldd librados2.so could give me some information.
It seemed that one of my Linux environments used the old buster kernel model, which was 12.2.* and not compatible with the new global ID reclaim. Another issue I got was that the windows client available for download uses a strange version 15.0.0 Pacific, which is just not correct. After reading and searching on GitHub, I realized that the windows executables could be built in a Linux environment using the ceph source code. So I've now built new binaries to windows that work just fine except for a libwnbd.dll which were never built. But adding it from the old installation, I got it to work. Now ceph-dokan reports a version of 16.2.5, which was the version I built. Building this was not straightforward, and something I think could be interesting for the community. So I'm planning to create an instruction video on the subject that I will publish next week. Again thank you for your help. Best regards Daniel On Mon, Aug 9, 2021 at 11:46 AM Tobias Urdin <tobias.ur...@binero.com> wrote: > Hello, > > Did you follow the fix/recommendation when applying patches as per > the documentation in the CVE security post [1] ? > > Best regards > > [1] https://docs.ceph.com/en/latest/security/CVE-2021-20288/ > > > On 9 Aug 2021, at 02:26, Richard Bade <hitr...@gmail.com> wrote: > > > > Hi Daniel, > > I had a similar issue last week after upgrading my test cluster from > > 14.2.13 to 14.2.22 which included this fix for Global ID reclaim in > > .20. My issue was a rados gw that I was re-deploying on the latest > > version. The problem seemed to be related with cephx authentication. > > It kept displaying the error message you have and the service wouldn't > > start. > > I ended up stopping and removing the old rgw service, deleting all the > > keys in /etc/ceph/ and all data in /var/lib/ceph/radosgw/ and > > re-deploying the radosgw. This used the new rgw bootstrap keys and new > > key for this radosgw. > > So, I would suggest you double and triple check which keys your > > clients are using and that cephx is enabled correctly on your cluster. > > Check your admin key in /etc/ceph as well, as that's what's being used > > for ceph status. > > > > Regards, > > Rich > > > > On Sun, 8 Aug 2021 at 05:01, Daniel Persson <mailto.wo...@gmail.com> > wrote: > >> > >> Hi everyone. > >> > >> I suggested asking for help here instead of in the bug tracker so that I > >> will try it. > >> > >> > https://tracker.ceph.com/issues/51821?next_issue_id=51820&prev_issue_id=51824 > >> > >> I have a problem that I can't seem to figure out how to resolve the > issue. > >> > >> AUTH_INSECURE_GLOBAL_ID_RECLAIM: client is using insecure global_id > reclaim > >> AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED: mons are allowing insecure > >> global_id reclaim > >> > >> > >> Both of these have to do with reclaiming ID and securing that no client > >> could steal or reuse another client's ID. I understand the reason for > this > >> and want to resolve the issue. > >> > >> Currently, I have three different clients. > >> > >> * One Windows client using the latest Ceph-Dokan build. (ceph version > >> 15.0.0-22274-g5656003758 (5656003758614f8fd2a8c49c2e7d4f5cd637b0ea) > pacific > >> (rc)) > >> * One Linux Debian build using the built packages for that kernel. ( > >> 4.19.0-17-amd64) > >> * And one client that I've built from source for a raspberry PI as > there is > >> no arm build for the Pacific release. (5.11.0-1015-raspi) > >> > >> If I switch over to not allow global id reclaim, none of these clients > >> could connect, and using the command "ceph status" on one of my nodes > will > >> also fail. > >> > >> All of them giving the same error message: > >> > >> monclient(hunting): handle_auth_bad_method server allowed_methods [2] > >> but i only support [2] > >> > >> > >> Has anyone encountered this problem and have any suggestions? > >> > >> PS. The reason I have 3 different hosts is that this is a test > environment > >> where I try to resolve and look at issues before we upgrade our > production > >> environment to pacific. DS. > >> > >> Best regards > >> Daniel > >> _______________________________________________ > >> ceph-users mailing list -- ceph-users@ceph.io > >> To unsubscribe send an email to ceph-users-le...@ceph.io > > _______________________________________________ > > ceph-users mailing list -- ceph-users@ceph.io > > To unsubscribe send an email to ceph-users-le...@ceph.io > > _______________________________________________ > ceph-users mailing list -- ceph-users@ceph.io > To unsubscribe send an email to ceph-users-le...@ceph.io > _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io