[Feature request] --home option at creating a new container

[VortexAcherontic]

Sorry for the issue spam though. But I also found it use full to have separate home directory to mitigate #19 I had this happen with regular distrobox-create command in the past and didn't found the exact root cause for this. Maybe it has something to do with my system ruining with locale: de_DE.UTF-8 and distrobox sometimes defaulting to something else?

Anyhow an option to specify a custom home directory for a container would be nice.

[Dvlv]

Already on the Roadmap.

https://github.com/Dvlv/BoxBuddyRS/blob/master/docs/ROADMAP.md

[Dvlv]

https://github.com/flatpak/xdg-desktop-portal/issues/475

Having this issue with the Flatpak version.

The GTK Filepicker will use the portal to select a custom dir, then mount that dir inside the flatpak sandbox. This will get a path like /run/user/1000/abc123/my_folder

The problem is, Distrobox itself is on the host, and that /run/user.... folder is not, so the box will fail to create.

I'm hesitant to add --filesystem=host to all installs, so I'm wondering if I should instead see if I can flatpak-spawn some command which checks if the user has manually added --filesystem=host via overrides/flatseal, and only show the option if they have.

Or perhaps I'm over-complicating it. I'll sleep on it and have a think.

[VortexAcherontic]

Oh, yes that is indeed true. Didn't thought about this even though I run all my apps as flatpaks, except the development environment which resided in a distrobox container 😄 .

I wasn't able to find a way to get the real path as well. All issues at portals or flatpak where closed as not planned and sure same issue for the volumes I see.

Another thing which comes to my mind with the filesystem access, even if some would allow for filesystem=home, would be that the flatpak will then write it's configs and stuff into the users home directory and no longer to .var/apps/app.id if I am not mistaken?

[Dvlv]

Another thing which comes to my mind with the filesystem access, even if some would allow for filesystem=home, would be that the flatpak will then write it's configs and stuff into the users home directory and no longer to .var/apps/app.id if I am not mistaken?

Not sure, but I don't write anything to the sandbox's XDG dirs anyway

[VortexAcherontic]

Maybe it's best to hide the row if is_flatpak is true until someone found a proper way to handle this, like:

    boxed_list.append(&name_entry_row);
    if !is_flatpak() {
        boxed_list.append(&home_select_row);
    }
    boxed_list.append(&image_select_row);

[VortexAcherontic]

Good morning, at least for me 😅 I thought about this too and came to the conclusion that the Roadmap feature to allow for running .dep und .rpm files inside a distrobox container would be affected as well by the sandbox?

[Dvlv]

Good morning (I'm in the GMT Timezone)

Yes probably, I gave toolbox-gui permissions for xdg-downloads and never ran into that issue, so I would probably just do the same for this (assuming it passes the Flathub linter)

[VortexAcherontic]

Hello there I had another idea on how we might deal with the sandbox issue:

Whenever the user will select a path which starts with /run/<user-id> we can be sure it's a sandbox path. In that case we might then display a warning that a sandbox path was selected and distrobox will not have access to it. Then request the user to allow BoxBuddy to access those directories either by using flatseal or flatpak overrides?

I did similar things, for all my flats to allow them access to my datalakes (two additional BtrFS volumes I have) so they can access them and the path is the same inside the sandbox as like outside.

[Dvlv]

Hello That would probably work, but I don't think it would be very good UX. If you show a user a feature then tell them they can't use it after they already try, you cause frustration.

Also, my time in the industry has made it clear to me that a lot of people don't read error messages - they screenshot them and open a ticket saying "I'm trying to do XYZ and this error appears" - even when the error itself tells them exactly what to do.

Thus, I'd much rather this option not appear unless it's (almost) guaranteed to work. The only way I can think of to do that is to try and read the user's overrides before deciding to display it.

[Dvlv]

1.1.0 released as binary and making its way through flathub now.