Hi Patrick, In tracker #20340 I've found that path-restricted mds caps can still occasionally trigger incorrect EPERM errors. It seems that sometimes Session::check_access uses a path looking like #<inode num>, which of course doesn't match the path restriction. Here is a *normal*, working check_access with stray_prior_path: 2017-06-20 11:22:38.489414 7f4fb4687700 20 Session check_access stray_prior_path /volumes/_nogroup/4722edf2-a761-4189-b925- dbf2d44c5345/aijens151.cern.ch/clone/modules/ironic/.fe57a500217328e0cb41c6e0731bf9ec3f949bff/.git/tvvy1sQ 2017-06-20 11:22:38.489417 7f4fb4687700 10 MDSAuthCap is_capable inode(path /volumes/_nogroup/4722edf2-a761-4189-b925-dbf2d 44c5345/aijens151.cern.ch/clone/modules/ironic/.fe57a500217328e0cb41c6e0731bf9ec3f949bff/.git/tvvy1sQ owner 993:991 mode 01 00600) by caller 4294967295:4294967295 mask 2 new 0:0 cap: MDSAuthCaps[allow rw path="/volumes/_nogroup/4722edf2-a761-4189- b925-dbf2d44c5345"] But then here is one with the inode num path, which returns Permission denied: 2017-06-20 11:22:40.736744 7f4fb4687700 20 Session check_access stray_prior_path #10000ee3d6f/tmp_obj_x3Ncq5 2017-06-20 11:22:40.736745 7f4fb4687700 10 MDSAuthCap is_capable inode(path /10000ee3d6f/tmp_obj_x3Ncq5 owner 993:991 mode 0100444) by caller 0:0 mask 1 new 0:0 cap: MDSAuthCaps[allow rw path="/volumes/_nogroup/4722edf2-a761-4189-b925-dbf2d44c5345"] 2017-06-20 11:22:40.736749 7f4fb4687700 10 mds.0.server reply_client_request -13 ((13) Permission denied) client_request(client.372408617:11903 lookup #10000ee3d6f/62f6fac09b5291e0924a6c844e11da53e40397 2017-06-20 11:22:40.734619) v3 Do you understand why these files get occasionally stuck with that funny stray_prior_path? Best Regards, Dan -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
