• 11 Posts
  • 866 Comments
Joined 3 years ago
cake
Cake day: July 7th, 2023

help-circle
  • Bud…been doing this for 20 years. Don’t need your explainer.

    The fact you didn’t mention the barest of minimums in your comment if where the issue lies. You’re just adding stacks on stacks of things by using any other network mount and having the user manage an encrypted image inside that mount. Also absent from what you were trying to explain. I’d work on that.

    Point being, for a multi-user/tenant utility like OP is asking for, there are better tools for the job, of which I just named a couple standalone options. If they are running TrueNAS, Synology, or QNAP, or even NextCloud, there are already built-ins for this purpose, and apps to match.

    If not, any of the other solutions I mentioned are much better suited for the use-case, especially, and if not only because, OP specifically said they DID NOT want exactly what you’re describing.


  • OP said they DON’T want LUKS. I’m also missing how the admin of the server (OP) wouldn’t have or store the keys unless and have these mounts available at all times?

    You seem to be suggesting there is some way for a remote user to mount a LUKS image on its host, which is not a thing unless you’re first SSH’ing to said host and mounting it and making it available for export mount elsewhere, which is clearly not what OP is asking for here when they just want space for people to store media. Maybe I’m misunderstanding.

    There Hook, Filen, Yeetfile, BatchIT…tons of these self-hosted stacks that do this with auth and user management built in. That’s what OP is asking about.







    1. No, you can’t “remove” your local networking interfaces from a container and expect it to use networking, anymore than you can remove the engine from a car, and expect it to drive. Set the default route of that container to some VPN tunnel interface, and you should be fine.
    2. I’m not seeing a link to any config
    3. 1000:1000 is usually the default user that is created for you when you setup a Linux system, so yes it’s reasonable for them to run as your user. It is NOT reasonable to run them as root, which is 0:0. Don’t do that.






  • I get that you’re aiming this at a user base of new folks and all, but I’m super confused to see Nix on there.

    This is kind of…Nix’s entire identity, no?

    One could also make the argument that this supercedes bootstrap tools that each distro has. Kickstart for example.

    I would maybe focus on making helper scripts that do specific things for groups of users, like installing all the steam-* packages for Steam installs and not just steam itself since this is pretty opinionated on how you’re choosing to install things re: native package manager vs Flatpak and such.







  • Okay, so that’s not what you’re describing at all. You can tell because people are responding with information, and you keep introducing trusts and turns like we’re supposed to know WTF you’re even talking about.

    Here’s how a gamepad works under Linux normally in a very simplistic way:

    Kernel > udev > HID Gamepad > libinput > game

    Where libinput sanitizes the input from the device and handles mapping. What you’re saying you’re doing is messing with permissions on the input device for some reason (which is unnecessary by any normal means), and then wondering why it’s not working.

    You’re saying your stack is functioning correctly for everything but Steam+Sunshine, right? You were told previously that steam-input runs when Steam runs. It essentially overrides libinput when running. THEN you’re throwing Sunshine into the mix, whiches uses it’s own input library as well, and you’re wondering what the issue is here.

    I’ll say it again, because you’re not listening: if everything works fine without Sunshine running, Sunshine is the problem. Libinput+steam-input+inputtino is going to cause problems. You’ve been told this before multiple times.

    Now, if everything is broken without Steam OR Sunshine running at all, then you have a libinput problem because you’re just running Sway without all the helpers that any usual DE would have, but you keep arguing against that idea for some reason, and I don’t think you understand what you’re even saying. On a normally functioning system, you don’t mess with permissions on /dev devices. If something isn’t working as you expect, you have issues downstream.

    So either start looking at your input library issues as you’ve been told a dozen times, or maybe boot a LiveUSB and see if everything works as it should without you messing with things.