Maya 2025-2026 on Linux

[modeler_pagan755]

Hi! Here is a topic about the two latest Maya versions, running on Linux.

Background: Maya runs just fine on Linux with Wayland session up to version 2024.

Current issue: starting form Maya 2025 (and now 2026), the Viewport 2.0 is black, and so is the UV Editor viewport. Possibly also other editors that use some OpenGL Qt view/widget.

The only solution is to switch to an X11 session. Installing it is not difficult, but this operation downgrades the whole Qt6 package ecosystem, along with all the system applications that rely on it. It goes without saying that this is not ideal (if not proper unacceptable).

This happens coincidentally with Maya switching from Qt5 to Qt6, which most Linux distros support both. However Maya's version is a bit older than what comes with most distros.

Now, the issue is Wayland compositor full support (which, again, works just fine up to 2024), considering that both GNOME and Fedora (the cutting edge "experimental platform" for RHEL and its down-streams, including Rocky)  are planning to drop support for Xorg (= X11) entirely on their next release.

Are you guys at Autodesk planning to take action and make sure Maya works on Wayland sessions? And not like "it goes for Maya 2027" kind of plan?

Companies can't keep using outdated software for much longer. 

Seriously, telling your customers to just switch to an X11 session is not a solution. It feels like Maya and most importantly on Linux is kind of a neglected child. 

I mean, Maya current situation:

glTF import/export support missing (which is good for use with game engines as well as an exchange format),

Collada export is broken for skinned meshes since Maya 2025 (open source glTF conversion tools from Khronos Group are based on that format) already reported mid 2024

https://forums.autodesk.com/t5/maya-forum/bug-collada-export-is-broken/m-p/13001759

https://forums.autodesk.com/t5/maya-animation-and-rigging-forum/can-t-export-an-animation-using-coll...

which hinders the use of a workaround to get the previous point sorted

FBX does not support the latest shaders you added and is locked at its 2020 version of development...which glTF would solve...

and now a second Maya version that's got the same issue on Linux running on a Wayland session and a historically relevant feature being broken for the same amount of time.

Please, seriously, please. Look into this Wayland compositor issue ASAP, for real. Or find a way for Linux users to make it work. X11 is not an acceptable solution.

Thanks

Edit to add:

@kelly_hynes @code13th01 @juan_bruscoQ3U5H 

even more context on how a by now 2 years old broken feature has not been addressed yet
https://forums.autodesk.com/t5/maya-animation-and-rigging-forum/cant-export-joint-skeleton-dae-on-ma...

specifically message 5

[velocity3dZ92QT]

Found a fix. The graph editor won't update unless the mouse leaves the graph editor window, or unless the animation is being played. I believe this is some compatibility issue with Xwayland. I got this python script that makes it always update every 100ms, the downside is that it spikes the GPU usage to 30% always.

import maya.utils as utils
import maya.cmds as cmds
from PySide6 import QtCore

def start_wayland_heartbeat():
    def force_refresh():
        if not cmds.play(q=True, state=True):
            # Using cv=True (current view) is slightly lighter than force=True 
            # if you find performance dips, otherwise keep force=True
            cmds.refresh(force=True)

    global global_heartbeat_timer
    global_heartbeat_timer = QtCore.QTimer()
    global_heartbeat_timer.timeout.connect(force_refresh)
    global_heartbeat_timer.start(100) 
    print("Wayland Graph Editor Fix: Heartbeat Active")

# This waits until Maya is fully idle/loaded to start the timer
utils.executeDeferred(start_wayland_heartbeat)

  This is vibecoded with ai, I'm very new at python, so if anyone else has a better solution I'd be very glad.

[anubis_loba]

Great job you're doing!

This forum is becoming more and more like a Blender forum, where people solve software problems, when it should really be a forum for helping colleagues with their problems or questions about using it. When you pay for a license, you expect the program to at least work. I still don't understand how Blender practically works even on a calculator, hahaha, and Maya, being a paid program, has users scrambling to find a way around it. By the way, if Mudbox isn't selling, why not integrate it into Maya? Well, that could blow up my PC, seeing how Maya runs on Linux; it's possible my PC would explode.

[luisalonsotechartist]

Just thought I'd report in with the release of Maya 2027. I have Maya 2024-2027 working perfectly with no hacks or issues in Rocky Linux 9.7. I have to do this each time there's a new release to support the plugins I have written with the Maya devkit for my students that depend on them.

Know that you won't get any support from Autodesk if you're trying to get Maya on anything other than what's found here:

https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/System-requirement...

I know it sucks to not have a choice of Linux distros, but it's an uphill battle you can easily avoid by simply using Rocky Linux 9. The choice is yours.

One last thing I would like to note: Autodesk is running out of time because RHEL 9 full support ends on May 31, 2027. Tick, tock, Autodesk.

[modeler_pagan755]

Sorry, but there's much to disagree upon with your statements.

First, as you noted, RHEL 9 is about to EOS.

Secondly, making Maya a tarball that contains ALL that is required to run, with no dependency hell, is straight forward and easier for them than maintaining a (always incomplete) list of dependencies for each version. The environments where Maya is being used is not the same as the greybeard linux user forums yelling "BLOAT!" at every library inclusion that is not relying on what comes with the distribution.

Third, and not less important, Wayland has started landing on every single desktop environment in every single distribution like what? 3 or 4 years ago? The fact that X11 would have been dropped was known since AGES. This is not acceptable in the slightest, and "simply use either RHEL or Rocky 9" sucks big time because heck, the solution is right there, in the second point. Which would have made Autodesk aware of the viewport issues quite a bit of time ago. And the choice belong to the user, sure: how many just moved on to Blender?

[velocity3dZ92QT]

Using X11 on a multi monitor 4K monitor setup is buggy. Wayland is needed ASAP. Any news in the 2027 version, is the support better?

[velocity3dZ92QT]

By the way, the article doesn't even include all the dependencies needed by the program. Try adding an audio file, it will ask for a missing dependency.  

[luisalonsotechartist]

Everything I said was factual and you might be surprised to know that I also agree with what you're saying, but someone reading this realistically only has 2 options for using Maya in Linux at the moment:

1) Use the Linux distro that Autodesk supports. This works perfectly, and I'm getting work done. This shouldn't be downplayed. 

2) Don't use the Linux Distro that Autodesk supports. This comes with problems that never end and you won't get any help. For crying out loud, we have people writing scripts that update the viewport every 100ms which spikes the GPU usage by an additional 30%. Hats off to the people trying to figure this out, but we lost the plot here. 

As for "RHEL 9 is about to EOS", not quite. RHEL 9 full support ends on May 31, 2027, and then it enters maintenance support for 5 years. Seeing that RHEL 8 is already in maintenance support and is supported by Autodesk, there's a good chance they might do the same with RHEL 9 simply because the cost of getting Maya to work on a modern distro is greater than the number of customers they will gain. I only mentioned it because it's yet another embarrassing thing for Autodesk. Frankly, even Maya 2027 is in an embarrassing state. They went with AI assistant instead of getting more important things fixed or getting a modern viewport like EEVEE in there. None of this changes the state that Maya in Linux is in. When it comes to Linux, I suspect Autodesk wants Maya to be used for render servers and never intended to have it be used by artists directly. Just a hunch, so I could be wrong.

At the end of the day, what are we doing on this forum? Are we trying to get the message to Autodesk to improve things? We've been trying this for years with no changes and Maya 2027 proves that. I think the best we can do is help others find a path to get things to work instead of keep trying to do Autodesk's job for them.

[luisalonsotechartist]

Like I said, zero problems.

[blendernoob64]

After much blood sweat and tears, I have finally gotten Maya 2027 (a version using the autodesk identity manager) installed in a Rocky Linux 9.7 distrobox on Bazzite Linux. Being this is a distrobox this should make it suitable to be installed on any Linux distribution out there. Granted being containerized brings some limitations, but for those who want to install Maya on any Linux, this is another option.

You need to enable EPEL in the distrobox, along with the init system, then you need to install Maya using the RPM packages and organically find the libraries you need to build an environment for Maya to live in. The trick is for the Identity Manager to actually log you in, you need an X11 desktop, and you need a web browser like Chrome inside the distrobox for the DRM to log you in (just something other than the browser installed on your host system, it can cause your browser info to be overwritten with Rocky's). I will record my findings on how I did it very soon, but this makes me very very happy.

But as others have said in this thread, just using Rocky Linux 9 is the path of least resistance and if you tinker with it, it is a really amazing, and stable distro. Using flatpaks and distrobox can allow you to bring all your favorite apps into Rocky and you will have very little compatibility issues, plus Maya will be happy to run on it. For as long as Autodesk keeps dragging their feet bringing the Identity Manager and their DRM into RHEL 10 and bringing Wayland support, I think we will keep making clever solutions to bring this program where we want it to, because we love it so much (and I am a paying customer).

Maya running in the Rocky distrobox in a VM. The error is relating to missing fonts. May look into that more.

Edit : I got Maya to launch in Wayland too! I just needed to install xhost and then add this to the .distroboxrc file in home :

xhost +si:localuser:$USER >/dev/null

I al;so ran this command outside of the distrobox before launching Maya just in case. I then was able to launch Maya in Wayland from the Distrobox.

[gigiovannivicentini]

AHHH great news. Congratulations for you work and discovery. There is any chance to make a Youtube video showing the steps?

[blendernoob64]

Yes I plan to. I have been making videos on getting Maya on alternative distros for a while now and this was a holy grail for me. If I learn more about containers and distrobox, I hope to make a Davincibox style installer but that is ambitious. Got to also see if we can put things like Renderman in the distrobox but again, I hope this  gets the conversation and collaboration on Maya on Linux going again.

[blendernoob64]

I just made a tutorial on installing Maya 2027 in a distrobox container in Bazzite Linux. I am so happy I managed to get this containerized solution for Maya up and running! Maya in distrobox can run on Wayland and with graphics acceleration through distrobox and can be installed on any distro! I heard on the grapevine that people installed Maya in studios in containers and I really wanted to learn how it can be done. I would say this is a proof of concept solution, as it is not perfect, but it is something to get the Maya on Linux community to celebrate. I am all ears for criticism on how to simplify the container and I hope to make an installer similar to Davincibox. 

Thanks to the entire Maya on Linux community for the help on getting Maya on unsupported distros.

[luisalonsotechartist]

Hey! First off, massive thanks for this video. It is a brilliant deep-dive into escaping the Autodesk RHEL-dependency trap we're in. I teach 3D rigging in Maya at a local college (with open-source plugins to help my students on any platform they use) and I'm also actively developing an indie game, so finding a way to run Maya on a daily-driver OS without dual-booting into an enterprise server distro would be fantastic.

I spent the weekend stress-testing your Distrobox method on both Linux Mint and CachyOS, and I wanted to share why I think your method works so flawlessly out-of-the-box on Bazzite, but requires a master's degree in system architecture for other distros. Bazzite's pre-configured ecosystem is built to solve host-to-container bridges that standard distros block by default. Here is the technical breakdown of the walls non-Bazzite users will probably hit (or at least that I found):

1. The GPU passthrough wall:

When you fire up Distrobox on Bazzite, your container instantly sees your GPU. On Linux Mint, the container engine is blind. Maya attempts to fall back to the open-source "nouveau" driver and instantly crashes. In contrast, Bazzite bakes the nvidia-container-toolkit and the exact CDI (Container Device Interface) specifications directly into its immutable core. On Arch/CachyOS, I had to manually install fuse-overlayfs to fix BTRFS podman conflicts, install the Nvidia toolkit, and regenerate the CDI locally just to stop the nouveau panic.

2. The Wayland/X11 Security Shield:

The Autodesk Identity Manager (and the main Maya UI) relies heavily on a bundled Qt framework. On Mint, the moment Maya tries to draw the splash screen, the host compositor aggressively blocks it, throwing a fatal IceTransSocketUNIXConnect error. Mint's Debian base enforces strict IPC (Inter-Process Communication) and AppArmor isolation, completely blocking Wayland/X11 socket sharing from unprivileged user namespaces. Whereas with Bazzite's Fedora Silverblue base comes pre-configured with socket-sharing exceptions explicitly to make containerized GUIs work. To bypass this on CachyOS, I had to manually install legacy xorg-xhost utilities, drop the host shield (xhost +local:), and force the engine to use a specific protocol bridge (QT_QPA_PLATFORM=xcb).

3. The "ADP Failed to Initialize" issue:

Even after bridging the GPU and punching a hole in the display server, Maya 2027 has an incredibly stubborn internal telemetry module (ADP) that fires before the UI initializes. If the container lacks a native web browser to handle the OpenID redirect, or if the container's Qt Wayland plugins clash with Maya's proprietary Qt6 bundle, the engine throws an "ADP Failed to Initialize" dialog and hangs indefinitely.

I'm hoping my findings can help the next person in solving this so we can use the Disrobox method with more than just Bazzite. In the meantime, I've been productive in my bare-metal Rocky 9.7 install and had no issues compiling plugins in Maya 2024-2027 as well as getting some work done with DaVinci Resolve on the same distro. Despite that, a RHEL 9 distro has its limitations (especially if you have an nVidia GPU). I still have to dual boot for other apps but I can see the day we have one Distro for all graphical needs in Linux.

Still, your video is an absolute goldmine of information for bypassing the Autodesk licensing daemon timeout. Fantastic work! Let's hope we figure this out. In the meantime, for anyone reading this, I would still recommend using the Autodesk supported Linux distros to avoid any of these headaches and getting work done without any issues... for now. Cheers!

[blendernoob64]

Thank you for the breakdown! The information will be so helpful. Maybe the universal blue folks will help us with replicating Bazzite’s behavior in other distros.

I just modified my Rocky 9.7 install with an upgraded kernel, and using flatpaks and distroboxes. It’s such a stable system and a great desktop for work and play. Maybe I can show that off too so others may use Maya in the environment it was meant for.