Check the groups the working user is included in, and make sure the non-working user is in those same groups. See if anything there.
Edit: Oh, you know what. I think this is probably Pipewire not starting for multiple users when multiple are logged in. On the non-working user, you need to start a unique Pipewire session for that user, because the other working user’s session can’t be shared by default.
Alpine is very specific in its use-case. Unless you know the exact package set you need to work with, it’s not suitable for general purpose use. It doesn’t even include glibc, for example 🤣 It’s meant to BARE as possible with a small footprint.
I’m not sure your rationale for picking Alipine for this use-case, but you might want to consider a more fleshed out distro for a NAS. Alpine is the BARE MINIMUM of an OS, meaning a lot of helpers that exist on other distros are not there for things like setting your power settings and link negotiations in certain cases. Sure the NIC driver is there, but all the nice tweaks for that specific module that exist in, say, Fedora Server aren’t going to be there, leading to this issue.
I’d honestly just throw FreeNAS, TrueNAS, or Unraid on this box and be done with it. They’ll have all the power settings and tweaks meant for a NAS in place, and then you won’t need to spend time hunting stuff like this down.
It could be related to power saving settings and/or your power profile.
Some Q’s:
I saw you tried to set power for the interface itself, but if this is a power issue, you probably want to disable power savings on your PCIe interfaces. Easiest way to do this is probably installing powertop, and navigating over to the ‘tunables’ menu, and disabling power management for those interfaces, just to test and see if it fixes it.
Your hardware is really the defining factor at the lower levels, but then whether you have encrypted partitions is the barrier at the OS level.
Understanding where your problem lies needs to be known, so more symptoms or logs would be helpful.
Nope.
Hate to keep litigating this around here, but the shift alone is enough. Explaining to people WTF an immutable filesystem is, is a sure way to frustrate them into giving up, despite whatever comms finesse you might THINK you have.
Counterpoint: STOP SUGGESTING IMMUTABLE DISTROS TO NEW USERS
For people who just want a functional OS, they don’t want to have to think about new rules. They need a quick off-ramp from Windows that acts as they expect.
Package management is already enough of a mindfuck for people switching, then you’re throwing in containers, permissions, flatpak vs native packages, what sandboxing is, why your browser likely can’t just upload a simple fucking file, and why your camera doesn’t work on Zoom, because you have a meeting in 10 minutes.
Unless you are handing people something akin to a mobile OS with everything all inclusive and configured so EVERYTHING works off the bat, you’re doing such a huge disservice to people switching over to an immutable distro, and there is ZERO benefit, but all kinds of added frustration.
You need to stop, and I yield my time.
Never go to a second location, let a third.
You in trouble.
It will TECHNICALLY still work at whatever version Nvidia cuts off support at, which is pretty soon for GTX cards (they’ve already cut off the mobile counterparts). So you’ll stop getting updates, but it should still work as long as that driver is made available still in some form that whatever distro you are using can install it, or you compile it from scratch. I would not trust Nvidia’s installer to still be working by then in it’s current form because it’s a MESS.
Seamless. Until you find something that isn’t. Report it if so.
Sounds like you need a client that does “multiparty uploads”. Meaning interruptions should continue if there is a break in comms.
All the Cloud endpoints support this, you just need a better client. Do some research I guess.
No, it’s not.
Never seen that, and I build with hundreds of variants from all the big manufacturers. Haven’t seen that once in a PC, Laptop, or SFF.
Yeah, but it’s almost pointless to give an “if, then, elsif, elsif” scenario if just removing the battery does the same thing, and all motherboards have a battery for the CMOS.
Did you read that I was saying containers are bad somewhere? You have misread.
Android Studio isn’t just a simple app, nor a single executable, AND it maps out to a bunch of local sockets to your already running host to provide various services. Certainly not going to be easy or stable in a container, especially since they are asking about emulation as well.
I’m confused by your question. Why would you need a container for this? There are other packages downloads for Android Studio. Container would be the most convoluted way of running it.
This sounds like you have beef with the developer.
What’s this post about?
If you don’t have an onboard display to plug into, open your PC, pull the CMOS battery for 30s, and plug it back in. This will reset all your settings to factory defaults.
Yeah, see my edit. This is a Pipewire session thing. Each user needs a unique Pipewire session to do audio. Video has nothing to do with Pipewire.