I found CryFS, the default encryption used, to become unusable if the vault is more than a few gigs in size* - gocryptfs works without issue.
* No, you dirty minded people, I use Vaults for client information at work, not what you were thinking of.
You can start it with systemctl start podman-auto-update.service It’ll auto update daily at 00:00.
Be aware you need to enable and start podman-auto-update.timer for this to work automatically (ie systemctl enable --now podman-auto-update.timer), this command will just update the images once only.
I don’t think this works for non-system podman images, so you’d have to do systemctl --user enable --now podman-auto-update.timer for each user.
You can use RequiresMountsFor= (eg RequiresMountsFor=/media/storage-volume1) instead of manually adding .mount to After/Requires - you can then use .mount files or fstab as you’re stipulating the path rather than a potentially changeable systemd unit name.
The systemd.mount manpage also strongly recommends using fstab for human added mount points over .mount files.
The 6.5 kernel should have the fix for this included, so you could try using that kernel instead of 6.1?
Sorry, I was thinking file browser mounts would appear in mount, but they don’t.
You should be able to list file browser mounts in a terminal using gio mount -li after mounting via the file browser, and it will list the SMB mount it’s using, ie smb://SERVER/$share/
This annoyingly doesn’t give us the username or domain for the SMB share, and to get that if the server and share looks OK we have to run gvfs (what the file browser for PopOS uses in the background) in debug mode and re-mount the SMB share; in a terminal run pkill gvfs; pkill nautilus; LANG=C GVFS_DEBUG=1 $(find /usr/lib* -name gvfsd 2>/dev/null) --replace 2>&1 ; this will unmount anything in the file browser but will show what username and domain the file browser is using to access the SMB share, for example after clicking on a share in the file browser, among other logs, I get;
smb: do_mount - URI = smb://absolution.local/samshared
smb: do_mount - try #0
smb: auth_callback - kerberos pass
smb: auth_callback - out: last_user = 'samblack', last_domain = 'SAMBA'
smb: do_mount - [smb://absolution.local/samshared; 0] res = -1, cancelled = 0, errno = [22] 'Invalid argument'
smb: do_mount - enabling NTLMSSP fallback
smb: do_mount - try #1
smb: auth_callback - ccache pass
smb: auth_callback - out: last_user = 'samblack', last_domain = 'SAMBA'
smb: do_mount - [smb://absolution.local/samshared; 1] res = -1, cancelled = 0, errno = [22] 'Invalid argument'
smb: do_mount - try #2
smb: auth_callback - normal pass
smb: auth_callback - reusing keyring credentials: user = 'samblack', domain = 'ABSOLUTION'
smb: auth_callback - out: last_user = 'samblack', last_domain = 'ABSOLUTION'
smb: do_mount - [smb://absolution.local/samshared; 2] res = 0, cancelled = 0, errno = [0] 'Success'
smb: do_mount - login successful
smb: send_reply(0x55ea6ffe5450), failed=0 ()
This should give the username and domain that connects and can be used in the credential file.
Once this is done, you can exit the terminal with gvfs running and you should be able to close and re-open the file browser and the mounts should just re-appear normally.
Hopefully this will give enough information as to why the file browser mount works and the mount command doesn’t.
OK, you may want to check dmesg or journalctl if there are further errors from the kernel - there is also a -v argument for mount, eg mount -t cifs -v //SERVER/$share /mnt --verbose -o... that might help.
Don’t know if you’ve found this already (and apologies if you have!) but this suggests some not obvious solutions https://superuser.com/questions/430163/cifs-share-mount-errors
Also (brain dumping) if you’ve successfully mounted it via the file browser, do so again and then check mount to see what arguments/options the CIFS mount is using - it might yield some important differences.
domain in this instance is the workgroup, and is optional according to the man page.
Have you tried adding --verbose before the -o? That might yield more information.
The GNOME extension appears to get the currently focused window information (ie name, title, PID and executable name) and make this information available over DBUS for the client binary.
The client binary calls
gnome-screenshot -fand I assume gives a path that the client binary then sends to Hubstaff servers.A janky suggestion would be to create a Kwin Script that pulls the active window information, sends it (somehow) to a DBUS service that can provide it to the client binary and create a wrapper script around
spectacleto pretend to begnome-screenshot(egspectacle -b -f $@)I don’t know if this would work fully though as the client binary strings seem to hint it checks the running version of GNOME Shell, and without an account I can’t see if this is a hard requirement or a “Hey, this is broken, we’ll try our best!” type thing.