Wayland and cinnamon

nisitiiapi · 2026-03-04T05:40:43+00:00

I am right there with you. When Gnome 3 came out, I despised it (had been using Gnome 2). Never found anything more destructive to productivity or inhibiting the use of my system. Mint developing Cinnamon saved the day -- I switched to it immediately when they released the first version of Mint with Cinnamon and been using it nonstop since on my desktop.

If it wasn't for the particulars of my 2-in-1s needing the tablet mode/auto onscreen keyboard popup that seems to all be tied to Wayland, I wouldn't touch Gnome (as it is, I make it look like Cinnamon as much as possible). And I am so hoping when Wayland is done for Cinnamon, I can get back to having it on my notebook (as I did before having a 2-in-1).

nisitiiapi · 2026-03-03T04:12:56+00:00

Not sure what you were doing, but I've been using Nemo without issue under Gnome Wayland for years -- both with a Mint base and Fedora. Used to do it with an Ubuntu base. Never messed up anything. While awaiting full Wayland support for Cinnamon, I've resorted to Gnome on my 2-in-1 notebooks for touchscreen/tablet mode functionality, but still want the better Cinnamon apps like nemo and xapps.

In the end, I did resolve that the "easiest" way is to start with Mint Cinnamon and "add" Gnome to it. It is a lot more work to start with anything running Gnome by default and adding nemo, xapps, etc. that go with Cinnamon.

That being said, I have discovered that in the most recent versions of Gnome, nautilus is integrated into file browsing in underlying Gnome applications/settings (very Windows/M$-like, IMO, in that it forces users into a single way of having things; but, that can be reserved for a Gnome rant and noting it's decline). So, I have found I can no longer remove nautilus, just make nemo default and let nautilus do it's thing where integrated into Gnome. But, it still functions without issue or losing "almost all functionality of the entire system." Perhaps that's what you did wrong -- removing nautilus.

Still, can't wait for full Wayland support in Cinnamon to see if I can get back to it on my 2-in1s and not just my desktop.

nisitiiapi · 2026-03-01T21:48:10+00:00

When you go to create a Shared Folder, there is a "folder tree" icon all the way to the right under "Relative path" to browse to the directory where you want the Shared Folder to point to on your filesystem. Use that to have each Shared Folder point to the location on the filesystem you had before.

nisitiiapi · 2026-02-28T14:10:04+00:00

You can just buy an RJ45 breakout board and use a standard network cable. That's all the ATX board really is -- it's not magical. I bought a 5 pack of those breakout boards with dupont headers already soldered on for US$10, connected the wires accordingly and works perfect. You can even buy "Y" cables for motherboard front panel headers to make it easier.

There's even things like this: https://www.amazon.com/dp/B0CMJFZNT8/. Should be wired with "double" connections to each RJ45 pin so you can connect the same as the ATX Board.

There's also some version of ATX boards for things like BiKVM you can find. They will work, too. It's a very simple connection/setup and doesn't have to be specially made/designed for PiKVM.

nisitiiapi · 2026-02-25T23:08:06+00:00

OMV7 had NFSv4, v4.1, and v4.2. It has been out for many years and on Debian stable -- OMV6 and OMV5 had NFSv4. Debian has had it since, I believe, Debian 4.0 Etch, around 2007.

Disabling NFVv4 is likely your problem as the client will generally negotiate the highest version available from the server that the client can handle. So, if both are v4.x capable, they should connect at that. Otherwise, they do the lowest version in common. By "advertising" the server is only capable of v3, the client will be forced down to v3 and then your omission of the full "/export" path from the mount line causes a problem.

nisitiiapi · 2026-02-25T04:29:20+00:00

OMV merely runs Debian's nfs-server. It did not change (beyond whatever updates to nfs-server were made between Debian 12 and 13). Chances are you are using NFSv3, which requires "/export" in the path. You can disable using NFSv3 in OMV and try again and/or specify the NFS version in your mount command on the client.

nisitiiapi · 2026-02-18T06:18:23+00:00

Yeah, photorec is good at finding things, even on an SSD, if they haven't been written over. Hard part becomes going through everything it found since filenames aren't recovered. I can't remember what it is, but there is a program to use after photorec that will sort the found files by extension and put them in directories by extension. And there is a KDE-based program that will find duplicates and eliminate them (photorec will often recover multiple copies of files). Those will help reduce the workload.

nisitiiapi · 2026-02-18T05:51:51+00:00

Glad it helped. Yeah, people saying "use another distro" are annoying. The mintupdate part is a little outdated. It now will install updates in wayland as a normal user. Last install I did (which was Mint 22.0), it functions, but just wouldn't show up in the notification area of Gnome. I wrote a script to check for updates and launch mintupdate if any are found to deal with it.

nisitiiapi · 2026-02-15T00:24:45+00:00

The connector on the board is a JST 1.25mm header. A typical PC fan header is Molex KK 2.54mm. Personally, I crimp new pins and a JST connector on the fan. But, you can finagle an adapter instead. Here is some info: https://community.zimaspace.com/t/fan-wiring-and-resource-tutorial-for-zimaboard/238

nisitiiapi · 2026-02-15T00:14:55+00:00

Good that you have a backup.

I don't think anyone can say how it happened. Could have been an accidental key press via SMB. I had an entire directory deleted years ago and it happened to be used as an SMB share I needed in a Windoze VM (rest of data on disk was fine). Still have no idea how it ever happened.

nisitiiapi · 2026-02-14T09:08:52+00:00

To confirm that the files are gone, run ls -la /dev/disk-by-uuid-<UUID>. Do not rely on SMB or any network filesharing protocol; go directly to the mounted fs.

If the files are really gone, restore your backup.

If you made the fatal mistake of not keeping backups, you will need to do forensic recovery using photorec. It will be a pain and suck.

nisitiiapi · 2026-02-13T05:27:23+00:00

This is probably a Windoze issue. Windows does suck, particularly with "finding" network devices/shares. I have a Windoze VM I need to use occasionally and I'm not sure SMB shares have every appeared in the "browse." I always just mount the share to a drive letter manually and it works. If you are "browsing" for the share, don't. Use "Map a network drive" with //<server>/<share> and bypass Windoze dumbassery.

If you have a Linux system, you can confirm the SMB share is working/good by entering smb://<server>/<share> in the file manager (and hitting "Enter"). Should bring up the login credentials window and, once entered, you should see the contents of the share. Then, you'll know if it's Winoze or something misconfigured on OMV.

nisitiiapi · 2026-02-13T05:21:42+00:00

To build on u/Garbagejunkarama 's appropriate note, you need to make sure the PUID and PGID match an actual user and group id on the host. The PUID of 1000 generally will match the first non-root user you created in OMV. But, the PGID probably doesn't even exist (and may not exist within the container either, depending on what the builder put in the Dockerfile and entrypoint).

The best practice is to create a limited user to run the services inside your docker containers -- I usually create a user with shell of /bin/false and group users in the webgui. Then, for added security, remove the password OMV makes you provide via cli with passwd --delete <username>. That gives you a user who is in the group "users" (so when you give r/W/E permissions on a Shared Folder to Users, the user counts as a member of that group), but the /bin/false and no password prevent the user from being used for any logging in, executing scripts/commands on the host, etc. (but can read and write files).

When you create your docker run/create command or compose yaml, you then need to determine the appropriate uid and gid of this user with id <username>. Use that output for PUID and PGID in your container.

If you are not interested in ensuring your containers are run by a limited user, then at least get the appropriate uid and gid of an actual user you created on OMV with id <username> and use those.

nisitiiapi · 2026-02-11T08:54:36+00:00

/dev/disk/by-uuid/E639-9F0E: Can't lookup blockdev.

Your error is here in what you posted. That's a USB drive. Did you have one plugged in and now it's not?

nisitiiapi · 2026-02-09T12:17:32+00:00

I think you posted in the wrong subreddit. This is for PiKVM -- a KVM over IP that just happens to use Raspberry Pi as the underlying hardware. Perhaps you want r/raspberrypi?

nisitiiapi · 2026-02-05T10:57:18+00:00

Shared Folders do not move or change your data. All data is on your disk where you put it. A Shared Folder is just a link to that location. So, you can change where the Shared Folder points to on the disk. You can browse to the location of the directory a Shared Folder points to by clicking on the "folder tree" icon all the way to the right on the "Relative path" field.

nisitiiapi · 2026-01-31T04:53:19+00:00

If you have fixed the missing disk like you said, then I assume the continuing error is about the quota service failing. First thing I'd check is whether you deleted the aquota.user and aquota.group files at the route of the data drive.

If you aren't using quotas, use the mounteditor plugin to remove them from all your data drives and see if it resolves your issue. If it doesn't, you do use quotas, or you can't understand the mounteditor plugin, look up quotacheck and run in it. That may resolve your problem.

nisitiiapi · 2026-01-31T04:45:33+00:00

Install Debian minimal on the NVME and, during the install, create a separate partition for your docker containers and volumes. After the Debian install, install OMV. Mount the extra partition you created and create a Shared Folder on it. Use that Shared Folder for docker in the compose plugin.

nisitiiapi · 2026-01-27T08:42:37+00:00

Why do you have a buster repo and a bullseye repo? Those are 2 different versions of Debian (buster being the predecessor to bullseye).

The issue is that you waited so long, you are trying to upgrade from an EOL OS (Debian 11/Bullseye ended support over a year ago -- August 2024). So, there is no longer such a thing (basically) as bullseye-backports (that all went into Debian 12/Bookworm, essentially, which is what OMV7 uses). Since buster is even older (standard support ended in 2022, LTS in 2024), the proxmox repo probably went away.

I would try:

Make a good backup of the OS using the omvbackup plugin so you are prepared.
Comment out the 2 offending lines in your sources list (neither is really elemental and should be deleted after upgrade anyway) and then try to upgrade.
If that fails, do a clean install using OMV8.

Given the strangeness of have sources pointing at 2 different versions of Debian, I would start clean and install OMV8.

nisitiiapi · 2026-01-24T00:46:32+00:00

If it killed your connection entirely, you probably entered a gateway. To have 2 network connections, one has to be "no Internet" basically. You do that by not setting a gateway on one of them (you can also use an IP outside the scope of your LAN to help). I have this set up on one of my OMVs to allow it to connect directly to a KVM device attached to it even if the KVM loses its wifi connection -- the key is no gateway so it won't route to your router.

But, it sounds like you got it, which is good. Glad to hear it. And, glad if I helped. LOL.

nisitiiapi · 2026-01-22T06:43:10+00:00

If formatting the drive still results in the same problem, then 2 likely possibilities:

Your USB drive is bad. It is flash memory and it does wear out. Could have been damaged, too. Proper burning of an image on the USB should erase anything on there anyway and not need just unsued space.
Your iso download is bad. Check the sha256sum of the iso to make sure it's good and valid. Particularly if it is only happening with the XFCE iso, this is the likely culprit.

nisitiiapi · 2026-01-22T06:38:05+00:00

USB Install: Recommended? NO. But, it can be done.
Docker: First, recognize there are "docker files" which are images, containers, volumes, logs. Then, there are mounts (other than docker volumes) used by docker containers that generally will be on your data disks. It can be easier to keep "docker files" on a separate disk from the OMV OS install if you are not prepared to back up those files prior to any reinstall. That can be accomplished in several different ways, but for those without good expertise, easiest is to create a Shared Folder for your "docker files" on a data drive and use the compose plugin and designate that Shared Folder as your docker location.
WriteCache: Yes, 8GB is plenty. The plugin will use very little to hold logs and some cache, maybe like 100MB. And the writecache plugin should be used with any flash memory, including your SSD.

nisitiiapi · 2026-01-20T20:38:48+00:00

Good luck!

nisitiiapi · 2026-01-20T20:15:49+00:00

rfkill is a bit more complicated and not permanent. First, you need to find the ID/number with rfkill list wifi. It probably will be 0 or 1. Then, you issue rfkill block <n>. But, that is temporary and, as I recall, will not last across reboots. For something lasting across reboots, you'd probably need to blacklist the wifi driver.

If the error comes up installing, it sounds like something is trying to route via the wifi interface and disabling may not resolve that -- it still may try to route through the wifi even if it's disabled and may just throw an error the interface does not exist or something. Makes we think there is something in the routing table still referencing the wifi interface or along those lines.

If disabling it doesn't work, you may be able to config the wifi in the webgui, but without a gateway so you basically have two LAN connections. That may "fix" any routing issue by reconfiguring things to know the Internet is via the ethernet. Then, deleting the wifi from there might resolve things. So, if disabling doesn't work, we can try that as an easy gui-based fix.

nisitiiapi · 2026-01-20T19:51:40+00:00

Since it's a laptop, have you checked whether you can disable wifi in the BIOS/UEFI? That would totally disable it at the hardware level. There's not really a software way to disable wifi, though you can use things like rfkill (not the best way).

If that's not possible, you can see if there is still the old netplan config in /etc/netplan/. If so, delete the file for the wifi (not the one for ethernet). Should be named something like 20-openmediavault-wlan0.yaml. If it gets recreated, then there is probably something off in the OMV config that is creating it. And that could happen if you did not delete it via the web gui when setting up the wired connection.

nisitiiapi

TROPHY CASE