Docker (new test version) does not show owner & group info in hamburger popup.

[marioscube]

The owner and group fields are empty.

if: docker exec -ti puptest /bin/sh

Logical, because the container does not know the names of owner:group 1000:1000 inside the container.

The simples of fixes is to no longer show this info.

Just show the permissions info and I'm happy.

I really like the keep it simple approach of pupcloud.
Just kill off features that do not work and only add features that dd to the functionality of pupcloud! NO need to make the code bloated (and slower) with exceptions and workarounds.

Maybe make this a discussion, not an issue?

[proofrock]

Thanks for your words, yes, it's the approach I'd like to take.

In the case at hand, here, the problem is that we have an information for that file (the numeric ID), so it's "wrong" that the code fails "just" because there's not a name associated to it. The "correct" way IMHO would be to display what you have, i.e. the number, and stop there (best effort).

Then if an user wants to do his own docker based on mine, and add the names, well, he could.

[marioscube]

Yes, but after some consideration, what does the info of owner:group add for the home user?
Nothing, the user set up pupcloud with his/her chosen user:group pair.

So remove it, problem solved.

If I should give a link to someone else (share) I do not want them to know the owner:group / PUID:GUID. That could be a security risk, or am I mistaken (I am slightly paranoid when I want to.)

[proofrock]

I don't really know what security risk may it pose, and also (truth to be told) what kind of usefulness may it have, other than "I cannot delete this, ah ok, it's not my file" kind of thing... I just think that if it's there, and doesn't "cost" much, the more information is shown the better. But you're the second person saying so, that's 2 versus 1, I'll think about it ;-)

[proofrock]

As a side note: I'm pretty busy these days. I'll begin work again in a couple of weeks; I am sorry, it's just to set expectations. In the meanwhile I'll try to consolidate all feature requests in a single discussion, close these issues and make a proper roadmap.

[DarrenPIngram]

I've added elsewhere my desire not to show this enhanced information, even if set as an env or something.

User-case, public sharing where there is not even an expectation of being able to do anything than download.

[marioscube]

As the main user I would like to know Owner Group and Permissions (Why can I not copy or delete a file?)

A shared user does not need to know this. A shared user can only view and/or download.

So show for main user, do not show for shared user.

[proofrock]

This seems reasonable (@DarrenPIngram what do you think?) but it doesn't solve the topic of this issue, that needs to be fixed anyway. Let's maybe spin it off to another issue?

[DarrenPIngram]

Yes, there can be different user cases for sure.

As long as it can be turned on, or off, with a share instance that is fine. If (as I FRed) there can be several users to the same instance, turning it on for John (if default is off) or vice versa is fine.

If it is easier, even turning the panel off or on is equally fine.

[marioscube]

I fear the topic of this issue cannot be fixed:

Pupcloud inside a docker container does not know the name of the Owner of the folder an/or file on the host system.

It;s a docker "issue". Don't fix. Put it down as a limitation of pupcloud inside docker.

I liked pup:pup so i knew I was inside a docker container.

EDIT:

I changed the Owner:Group of a directory to root and a file to www-data:www-data. This showed op:

Root is ok, but www-data is NOT xfs !!! :-)

[DarrenPIngram]

Having it turned on (explicit) may solve the problem so it looks normal in Docker? Everyone's wishes work then (default is off, switchable on, or vice versa). That said, my test of Pupcloud is running inside docker and connecting externally to that VPS does show the owner info (and stuff I'd rather not have there). https://take.ms/5N2Bq

…

On Wed, 11 May 2022 at 13:14, marioscube ***@***.***> wrote: I fear the topic of this issue cannot be fixed: Pupcloud inside a docker container does not know the name of the Owner of the folder an/or file on the host system. It;s a docker "issue". Don't fix. Put it down as a limitation of pupcloud inside docker. I liked pup:pup so i knew I was inside a docker container. — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABV5MAAXAYY3QS7GM6VXVDDVJOCBJANCNFSM5VO4Q6YQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[proofrock]

Yes, that was before the latest changes in the develop branch (that's why "new test version" is in the title). But it was accidental: pup:pup is 1000:1000, and your files happen to be owned by 1000:1000 (that's the first account in a system, usually). So if you had another user, it would show '--'.

[DarrenPIngram]

Ah, sorry missed that. Maybe I should change my test Docker to pull the latest versions (is it packaged? and a specific image tag?)

…

On Wed, 11 May 2022 at 13:21, Germano Rizzo ***@***.***> wrote: Yes, that was before the latest changes in the develop branch (that's why "new test version" is in the title). But it was accidental: pup:pup is 1000:1000, and your files happen to be owned by 1000:1000 (that's the first account in a system, usually). So if you had another user, it would show '--'. — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABV5MAASXNACIDPAPKMUQ2TVJOC2BANCNFSM5VO4Q6YQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[marioscube]

@proofrock true

Please see my edit on previous reply.

[proofrock]

is it packaged?

Check issue #30 for a backstory, the test image is listed there but it just solves that error.