Error when saving MLX file

I am using MATLAB R2022a in Ubuntu 20.04.5 LTS (Kernel 5.15), and whenever I try so save a .m script file I have no issues, however when I try to save a Live Editor file (.mlx), I get the next error:

Unable to save file myFile.mlx

java.lang.RuntimeException: Internal Exception in writing MLX file : Could not commit changes: copy failed: fl:filesystem:SystemError: /tmp/.bdae-ce03-39f3-5965.tmp invalid cross-device link

I have tried with R2022b, but the problem persists. I have another Ubuntu station (Kernel 5.4) and it does write the file. I have read about similar errors depending on the Kernel version. Is there any solution that does not include downgrading the Kernel?

Answer 1

[Sailesh Kalyanapu]

I understand that you are getting an error when saving 'MLX' files in MATLAB R2022a and R2022b.

This is a known issue with MATLAB R2022 releases. Currently, these are the following workarounds other than downgrading the Linux kernel:

1) Change the temp directory of MATLAB to a new folder

The default temp directory of MATLAB on Linux is '/tmp/', to resolve the issue, you can create a new folder in a different file directory and set it as the new temp directory.

Please refer to the following example to change the temp directory of MATLAB in the MATLAB Command Window:

>> clear all 
>> tempdir  % ans = '/tmp/' 
>> setenv('TMPDIR', 'FILE DIRECTORY FOR THE NEW FOLDER') 
>> clear all 
>> tempdir % ans = 'FILE DIRECTORY FOR THE NEW FOLDER'  

You should be able to save all MLAPP files/ Simulink models/ Live Scripts as usual after changing to the new temp directory.

If the above workaround does not resolve the issue, try to

2) Use MATLAB Online:

MATLAB Online provides access to the latest version of MATLAB from a standard web browser using MathWorks-hosted computing resources and storage, which allows you to continue working with your previous files and related datasets.

Please refer to the following link to upload the files to MATLAB Online and download files from it: https://www.mathworks.com/help/releases/R2022b/matlab/matlab_env/access-files-in-matlab-online.html

If you would like to know more about what is MATLAB Online, please refer to the link below: https://www.mathworks.com/help/releases/R2022b/matlab/matlab_env/what-is-matlab-online.html

[Agustín]

Thank you for this answer!

I have updated my S.O. to the 22.04 version, and in both cases I have the same kernel version. I have observed that I need the solutions you proposed above if MATLAB is installed in $HOME instead of /usr/, /opt/...

[xingxingcui]

thanks!

similar issue:

How do I fix this error "Could not commit changes: copy failed: fl:filesystem:SystemError:" please?

https://www.mathworks.com/matlabcentral/answers/1846668-how-do-i-fix-this-error-could-not-commit-changes-copy-failed-fl-filesystem-systemerror-please

desktop matlab R2022b, ubuntu20.04, solved!

------------update----------------

Is there a way to permanently set the "TMPDIR" environment variable when the matlab software restarts and fails? Trying to set it in .bashrc does not work

[Joshi Kumar V]

didn`t worked for me!

followed the steps mentioned about , but unable to save live scirpt.

I am using Ubuntu 22.04 and Matlab R2022a with kernel 5.15.0-53-generic.

Any other work around solutions ?

Thanks in advance

Joshi

[隆支 鈴木]

>>"1) Change the temp directory of MATLAB to a new folder”

I was unable to solve the problem using only this method.

I solved it by adding a change of location of the .mlx file from the external storage (HDD) to the location of the home directory.

The following is my environment

• Ubuntu 20.04.5 LTS
• R2022b

[Mohsen Raoufi]

It doesn't work for me neither.

Matlab R2022b

Ubuntu 20.04.5 LTS: kernel 5.15.0-56-generic

[Riccardo Scorretti]

I'm sorry to say that it works for me, but only partially.

I run Fedora 37, kernel version = 6.1.5-200.fc37.x86_64.

I'm using the software gocrypt to ecrypt the directory which contains my work. Basically, it works like a volume which has to be mounted when I start my PC -- let say that /home/scorretti/private is the mounting point.

I created a directory in my home directory, then I set it as Matlab temporary directory:

mkdir /home/scorretti/.matlab_tmp_dir

setenv('TMPDIR', '/home/scorretti/.matlab_tmp_dir')

clear all

tempdir % just to check that the temporary directory is correctly set

Up to my understanding, the problem comes up when the temporary directory is on a different volume than the volume where the file has to be saved. The previous code doesn't allow me to save the in my enchrypted volume. In order to work, I must set as temporary directory a directory inside the enchrypted volume: that's work:

mkdir /home/scorretti/private/.matlab_tmp_dir

setenv('TMPDIR', '/home/scorretti/private/.matlab_tmp_dir')

clear all

This seems coherent with the observation by 隆支 鈴木. There is a technical discussion on a similar issue on unix.stackexchange.com:

https://unix.stackexchange.com/questions/79132/invalid-cross-device-link-while-hardlinking-in-the-same-file-system

I hope this problem will be solved in the next upgrade of Matlab.

[Charles Ragan]

I was having this issue with not being able to save mlx files in R2022b in MOS on OpenShift. The solution above worked for me.

Answer 2

[Charles]

I am having this problem, too, but the above work-around does not work.

Without the work-around, I get this error dialog:

This mentions the "cross-device link".

Then I change the temp directory to one under my home dir: '/home/cwright/.matlab_tmp/'. I open a new model in Simulink, add one block and try to save. I get this error dialog:

Clearly, the new temp dir isn't good enough. So I close the file without saving, then attempt to exit Matlab. The GUI disappears, but the process never quits, in fact it starts taking 100% of the CPU (single core) and requires manually killing. This happens with or without the temp dir change.

This is pretty frustrating, as I'm on a trial Simulink license. Simulink works perfectly on my machine at work, but not my home machine. Both are running Linux Mint 20.3 with identical kernels:

Linux 5.15.0-48-generic #54~20.04.1-Ubuntu SMP Thu Sep 1 16:17:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

They are two different processors and mainboard. I guess the next step is to downgrade the kernel, but I'd appreciate other suggestions.

Charles