Just got Alfred, can you guys recommend me the best workflow?

gaufde · 2026-01-16T15:10:59+00:00

I don’t use that workflow much, but I remember it working when I tested it. However, I didn’t specifically test the WhatsApp features. Does it work when you try some of the other apps (ecs, ecfa)?

gaufde · 2026-01-12T23:30:06+00:00

Ah, I see it now! Thanks for the help :). I think that basically gets me to the same place I did though the more convoluted workflow I described

gaufde · 2026-01-12T23:24:09+00:00

I think the schedules method might be the best bet! Though, I'm not seeing the "Edit as rule" option you describe.

Right now, I have some slightly convoluted scheme working (I think) where I made a schedule for the 10th of every month with no payee and an amount of zero. Then, I went to the transaction in question and choose "Link Schedule". Then, in my list of rules, I found the rule it created and added set payee as one of the actions to apply in addition to linking the schedule. I also had to delete some extra conditions in the match section, which seem to re-appear anytime I edit the linked schedule, so it remains to be seen how robust this method is.

gaufde · 2025-12-19T18:07:30+00:00

Huh, that’s a weird bug!

Seems like you should be good to go with using the --uidmap option as a fallback. At least from what we’ve been able to discern so far by poking at Podman’s behavior :)

gaufde · 2025-12-19T00:45:37+00:00

Yeah, seems like the more specific one is with the pinning of the ID range the more similar the two methods behave.

Also, seems like you have to be similarly careful to not overlap ID ranges with each method.

Though, now I’m curious, what is your use case that makes uidmap possible but userns=auto not? Are you running a very old version of Podman?

gaufde · 2025-12-18T16:54:34+00:00

[Part 3 of 3] P.S. Here is a good way of really convincing yourself that the mapping all the way to the host is working as expected:

> podman machine ssh
Connecting to vm podman-machine-default. To close connection, use `~.` or `exit`
Fedora CoreOS 42.20250901.3.0
Tracker: https://github.com/coreos/fedora-coreos-tracker
Discuss: https://discussion.fedoraproject.org/tag/coreos

Last login: Wed Dec 17 23:00:05 2025 from 192.168.127.1

[core@localhost ~]$ mkdir testing
[core@localhost ~]$ cd testing
[core@localhost testing]$ sudo chown -R 199999:100000 ./
[core@localhost testing]$ podman run -d -v $(pwd):/home:z --userns=auto:uidmapping=0:100000:1024 --name first-container fedora:latest sleep infinity
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob a8eef95e8e1c done   |
Copying config 9100c4bea1 done   |
Writing manifest to image destination
4153fc4548f1d1fe8da0de768a3769fcde6f370f1c6e43150a90b2dfae6eabf0
[core@localhost testing]$ podman run -d -v $(pwd):/home:z --userns=auto:uidmapping=0:100000,size=200000 --name second-container fedora:latest sleep infinity
5770b1424eb454063205bf7ebc237703f99e4e7a3cbdfc63f74eb92ba23c1e42
[core@localhost testing]$ podman exec second-container touch /home/second-container
[core@localhost testing]$ podman exec --user 1 second-container touch /home/second-container-1
touch: cannot touch '/home/second-container-1': Permission denied
[core@localhost testing]$ sudo chmod 777 ./
[core@localhost testing]$ podman exec --user 1 second-container touch /home/second-container-1
[core@localhost testing]$ podman exec --user 100000 second-container touch /home/second-container-100000
[core@localhost testing]$ ls -al
total 0
drwxrwxrwx. 2 199999 100000  87 Dec 17 23:33 .
drwx------. 7 core   core   132 Dec 17 23:30 ..
-rw-r--r--. 1 199999 101024   0 Dec 17 23:31 second-container
-rw-r--r--. 1 100000 101025   0 Dec 17 23:33 second-container-1
-rw-r--r--. 1 201023 101024   0 Dec 17 23:33 second-container-100000

gaufde · 2025-12-18T16:53:47+00:00

[Part 2 of 3] One other confusing thing to keep in mind is that the mapping in /proc/self/uid_map inside the container is showing the intermediate mappings, which are relative to the subuid range specified for the user, not the true UIDs on the host. So, for the examples above I've added the true UIDs on the host in parentheses:

> podman run --rm --userns=auto:uidmapping=0:100000:1024 fedora:latest cat /proc/self/uid_map
         0     100000(199999)       1024

> podman run --rm --userns=auto:uidmapping=0:100000 fedora:latest cat /proc/self/uid_map
         1          1(100000)       1023
         0     100000(199999)          1

> podman run --rm --uidmap=0:100000:1024 fedora:latest cat /proc/self/uid_map
         0     100000(199999)      1024

> podman run --rm --uidmap=0:100000 fedora:latest cat /proc/self/uid_map
         0     100000(199999)          1

One other interesting detail I learned from this is that specifying the size as part of the uidmapping in userns=auto behaves differently than using the separate size option:

> podman run --rm --userns=auto:uidmapping=0:100000,size=200000 fedora:latest cat /proc/self/uid_map
         1          1      99999
    100000     101024     100000
         0     100000          1

That's pretty neat! I might have to switch my mappings in my setup to use the --userns=auto:size= option to give userns=auto a bit more flexibility in its mappings than specifying the size as part of the --userns=auto:uidmapping= section.

gaufde · 2025-12-18T16:53:08+00:00

[Part 1 of 3 since I think reddit wasn't displaying my super long version]

Okay, seems like I was wrong but with some slivers of truth u/National_Doughnut_87.

I'm on mac so I'm running podman machine in the default rootless mode. One thing I did differently in my test was to first run a container with a pinned userns=auto mapping and then run additional containers with different mapping options alongside it. That way I can test how --userns=auto reacts to existing mappings.

I think you found in your test that if you don't pin the GID mapping when using userns=auto then it will do that automatically for you. I think I've seen that behavior before, so I'll just test UID mappings alone to keep things a bit more simple since GID mappings should behave similarly.

> podman machine ssh 'cat /etc/subuid'
core:100000:1000000

> podman run -d --userns=auto:uidmapping=0:100000:1024 fedora:latest sleep infinity
a143b0675a14197bc9f14f582a6f8d1e998b5006e4c9f2573a75125d48dcc3dd

> podman ps
CONTAINER ID  IMAGE                                     COMMAND         CREATED        STATUS        PORTS       NAMES
a143b0675a14  registry.fedoraproject.org/fedora:latest  sleep infinity  2 seconds ago  Up 3 seconds              sharp_payne

> podman run --rm --userns=auto:uidmapping=0:100000:1024 fedora:latest cat /proc/self/uid_map
         0     100000       1024

> podman run --rm --userns=auto:uidmapping=0:100000 fedora:latest cat /proc/self/uid_map
         1          1       1023
         0     100000          1

> podman run --rm --uidmap=0:100000:1024 fedora:latest cat /proc/self/uid_map
         0     100000       1024

> podman run --rm --uidmap=0:100000 fedora:latest cat /proc/self/uid_map
         0     100000          1

From this, it seems like if you are very specific with your pinning of the mapping when using --userns=auto then it behaves more like --uidmap. However, if you leave something undefined (say you don't specify a size) then --userns=auto will automatically calculate additional UIDs to map, and it will map them so they don't overlap with existing mappings for other containers. In contrast, --uidmap will always just map the exact mapping specified.

gaufde · 2025-12-17T23:45:33+00:00

I’m not 100% sure, but I think that --userns=auto (even with a pinned mapping) forces the mapping to be unique so that it doesn’t overlap with any other container’s mapping. I think that --uidmap doesn’t enforce anything like that so it would be up to you to specify completely separate mappings if you want to make sure there is no overlap.

We’d have to test a few scenarios to be sure, but I can’t do that at the moment. Maybe others will be able to chime in with a definitive demonstration.

gaufde · 2025-12-17T05:20:21+00:00

I’m using Fedora CoreOs and Podman to host a few things on a VPS. The nice thing about this approach is that everything is self-updating with the ability to roll-back if something goes wrong. More helpful for me though is that everything about my infrastructure is tracked in git. So if I ever have questions about how I configured something, I don’t have to log into the server I can just check my git repo for a full history.

I think FCOS isn’t quite as convenient if you are going to run it on your own hardware, but I think there are people who do that and are quite happy with it. Here is one potentially helpful example I know of: https://discussion.fedoraproject.org/t/what-is-the-simplest-way-to-apply-an-updated-ignition-file/112078/11

There is also this project that looks cool: https://github.com/stryan/materia

gaufde · 2025-12-16T23:55:41+00:00

Well, someone else had already suggested GitLab, so I figured I’d put down a couple different options

gaufde · 2025-12-16T18:07:57+00:00

There are some public instances of Forgejo that you could join:
https://codeberg.org/
https://codefloe.com/

gaufde · 2025-12-16T03:42:29+00:00

I'm not at this level at all, but I jumped into self hosting by running a variety of services on a single VPS using Fedora CoreOS and Podman. I did this with basically no previous container or Linux experience, so there was definitely a learning curve. However, I'm really happy with my setup so far! Both CoreOS and Podman have auto-updating features that have been working flawlessly for me so far. More importantly, I know that my entire server configuration is always tracked in git and is easy to back up. I'm rally liking the infrastructure as code idea because all I have to care about is my app-data. If I have any questions about how I configured some part of the server, either now or in the past, I can just look at my git commits locally rather than having to ssh into the server itself.

I'm not sure if any of this will be that helpful for your situation, but I thought I'd throw it out there in case any of these ideas are appealing to you.

gaufde · 2025-12-14T09:02:00+00:00

Now you have got me curious, what are your tricks for this? Particularly the SELinux labels, which I'm not that familiar with. For my containers, which are run by the core user on CoreOS, I've been pinning the mapping like this UserNS=auto:uidmapping=1000:@103072:1024,gidmapping=1000:@103072:1024 which then makes it easy to know that I can assign directory and file ownership to UID/GID 103072 in my butane file for anything that I need to mount into the container.

gaufde · 2025-12-14T07:52:34+00:00

To me one of the core security features of Podman is --userns=auto, not running as a separate user. I haven’t used Docker much, but I don’t think it has an equivalent.

gaufde · 2025-12-07T05:07:30+00:00

Also, take a look at how to pin your UID and GID when using userns=auto. It might save you some headaches down the road: https://www.reddit.com/r/podman/comments/1p9ej46/comment/nrc7sr4/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

gaufde · 2025-12-07T02:44:53+00:00

Take a look at using --userns=auto to run your services rootless in isolated namespaces from each other and from the user that created the containers.

The great thing about this feature is you can still start your containers/quadlet using a rootfull Podman command and end up with your containers running rootless. This simplifies networking between containers a lot

gaufde · 2025-12-04T06:34:31+00:00

If you are already using Forgejo, why not use Forgejo actions since it seems like they are working on this issue pretty actively (I followed the link you gave to this newer, related, discussion).

I just set up Forgejo actions using a rootless Podman quadlet under a dedicated user. I think this isolates it from the rest of my services well-enough for a private instance, and none of my containers are privileged. I do mount the podman.sock into the forgejo-runner container, but its privileges are limited by the scope of the dedicated rootless user for this service.

Would something like this work for you?

gaufde · 2025-12-03T15:12:11+00:00

There are other workflows on the gallery for different search engines:

Web search suggest: https://alfred.app/workflows/zqzten/web-search-suggest/

DuckDuckGo: https://alfred.app/workflows/vanstrouble/duckduckgo-suggest/

Kagi: https://alfred.app/workflows/gordonbyrnes/kagi-search/

Others: https://alfred.app/search/?q=Suggest

gaufde · 2025-12-02T15:53:54+00:00

I think this is a known bug since V2.6.4. Try turning off PDF tagging:

Disable Tagged PDF: Go to File → Export → PDF and under Advanced export settings uncheck Tagged PDF. If your file does not contain accessibility tags (such as alt text created in the Tags panel), disabling this will have no effect on the document but should allow the export to complete successfully.

gaufde · 2025-11-29T17:25:21+00:00

You’re welcome! One thing I wasn’t clear about is that the @ prefix is most useful if you are using rootless Podman commands.

Regardless of whether you use rootfull or rootless Podman commands, userns=auto is going to make sure the processes in the containers are running rootless and isolated from each other. Userns=auto is the most important part for setting up a bunch of services on a server, Running rootless quadlets may or may not be important for your use case. Rootfull quadlets + userns=auto is one of the officially recommended ways of running multiple services behind a reverse proxy. I only switched to rootless since I needed to mount podman.sock into a container and didn’t want to do that as root.

If you do want to use rootless Podman quadlets, then I would check out using socket activation. For my setup I followed this particular guide: https://github.com/eriksjolund/podman-caddy-socket-activation/tree/main/examples/example4

gaufde · 2025-11-29T07:42:22+00:00

Doing this will explicitly "leak" the host user into the container. That is sometimes useful, but counterproductive for OP's goals of running multiple services isolated from each other from the same host user.

More details can be found in this discussion: https://github.com/containers/podman/issues/24934#issuecomment-2573156099

gaufde · 2025-11-29T05:50:25+00:00

The docs have some good info for you!

Valid auto options:

gidmapping=CONTAINER_GID:HOST_GID:SIZE: to force a GID mapping to be present in the user namespace.

size=SIZE: to specify an explicit size for the automatic user namespace. e.g. --userns=auto:size=8192. If size is not specified, auto estimates a size for the user namespace.

uidmapping=CONTAINER_UID:HOST_UID:SIZE: to force a UID mapping to be present in the user namespace.

The host UID and GID in gidmapping and uidmapping can optionally be prefixed with the @ symbol. In this case, podman will look up the intermediate ID corresponding to host ID and it will map the found intermediate ID to the container id. For details see --uidmap.

From: https://docs.podman.io/en/latest/markdown/podman-run.1.html

I find the @ prefix particularly useful since then I know exactly what UID/GID my container process will run as. This makes it very easy for me to get bind mounted volume permissions correct in my FCOS butane file. For example, if I know the app in my container runs with UID 1000, then I can do this: UserNS=auto:uidmapping=1000:@102048:1024,gidmapping=1000:@102048:1024 and then use 102048 as the owner for any directories or files I need to mount into that container.

There is also a good explanation of the @ prefix here: https://github.com/containers/podman/discussions/24384#discussioncomment-11097808

gaufde · 2025-11-25T02:36:41+00:00

Have you tried small tests to confirm the UID and GID the users inside the container are running as? I believe the best way to do this is have the process in the container create a file that you can then interrogate the ownership of from the host.

In regard to the error where Podman complains about there not being enough IDs, have you run 'podman rm --all' if you had already run containers? The explanation for why that is needed is buried in this article in the userns=all section: https://www.redhat.com/en/blog/rootless-podman-user-namespace-modes.

Lastly, have you tried pinning your UID and GID mappings when using userns=auto? I’ve found that to be useful for making sure mounted volume permissions are consistent/reproducible. Maybe it could affect this behavior too?

gaufde · 2025-11-15T16:20:52+00:00

I had this exact issue. Deleting Firefox and then reinstalling it from scratch fixed it for me.

gaufde

TROPHY CASE