Open Stack

When we were debugging this issue in IRC it appeared that the issue was
related to the introduction of O_TMPFILE support in Swift.  Can you
confirm that everything is still working properly when you force swift not
to use o_tmpfile/linkat?

The linkat detection has improved in subsequent releases of Swift, but it's
still not clear the latest version would be properly workaround whatever
issue your setup is having.

When I google for O_TMPFILE and EPERM I see that there was bugs filed
against glibc shortly after O_TMPFILE support was introduced to xfs.  Can
you share the output of "uname -a" and "ldd --version"?  Perhaps we could
discover or develop a base box image that can reproduce the error.



On Tue, Mar 3, 2020 at 6:39 AM Gui Maluf <guimalufb at gmail.com> wrote:

> Hi all,
>
> I'm struggling with something really wierd. 3 weeks ago I started
> upgrading my Keystone + Swift Ubuntu environment from Kilo to Queens. So I
> moved from Ubuntu 14.04 to 18.04.
>
> I can create new accounts and containers. But no objects. I think between
> Mitaka and Newton my storages started to throw Permission Denied error
> while writing object metadata.
>
> I saw that the piece of python code where I getting problem was changed in
> Rocky version and in hope of getting things fixed I've upgraded storage
> version. But the error persists.
>
> http://paste.openstack.org/show/790217/
>
> I've check everything I could, user, permissions, mount options. But I
> still getting this error.
>
> I wrote a python script for creating files and writing metadata within the
> swift mount with swift user and everything works fines.
>
> Don't know what to do anymore. This is a "dev" environment with two
> storages only and a few disks.
> Since I'm planning to do in the production environment I'm quite scared if
> this happens again.
>
> Thanks in advance
>
> --
> *guilherme* \n11
> \t *maluf*
>


-- 
Clay Gerrard
Wyatt Elementary Dad's Club Chair 2019-20
210 788 9431
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200303/7de0cf4e/attachment-0001.html>