Matlab preferences not being saved across sessions.

Hey there!

I recently installed Matlab on my Linux machine.

When ever I try to change font and colours of the UI, the change is not persisted. It resets back to default.

Even the add-on download dialog asks me to sign in every time.

Strangely, the keyboard shortcuts option, has the changes saved.

I am attaching a video for reference. - Link - Video Recording

I did email Mathworks support regarding this, its been a week since I emailed them. They did follow up, but none of their solutions worked.

Do let me know if anyone needs any additional details.

[dpb]

See about killing the existing and recreating new preferences file <How-do-i-regenerate-my-matlab-preferences?>

I'd also ensure there somehow isn't a zombie MATLAB process still running -- not sure what it's called in Linux, but whatever is the TASKKILL or way to see/ensure there aren't any other processes in memory that didn't get killed cleanly before.

It that doesn't solve it, I'd not let go of the existing case number yet; my experience has been Mathworks support will continue to work on something until it's resolved or clearly a bug for which there is no workaround. This is, afaik, not an issue that seems to be highly prevalent so it would seem it should be solvable.

[Dilip Parasu]

Thanks for your reply!

Regenerating matlab preferences was recommended by matlab support. Unfortunately it did not work out.

As for killing matlab process, I am sure that all matlab processes are dead.

I am not leaving matlab support, I asked here just in case someone else came across this same bug.

[Walter Roberson]

Could you confirm that you have write access to prefdir()?

fileattrib(prefdir)

[Dilip Parasu]

Yes I do have the needed permissions.

>> fileattrib(prefdir)

            Name: '/home/venom/.matlab/R2022a'
         archive: NaN
          system: NaN
          hidden: NaN
       directory: 1
        UserRead: 1
       UserWrite: 1
     UserExecute: 1
       GroupRead: 1
      GroupWrite: 0
    GroupExecute: 1
       OtherRead: 1
      OtherWrite: 0
    OtherExecute: 1

[Walter Roberson]

 ! ls -ld /home/venom/.matlab/R2022a

and verify that the owner is your account?

Also, to check, you are running matlab under your own account, not sudo, right?

And prefdir is on a local filesystem that is mounted read/write, not readonly and not a network file system?

[Dilip Parasu]

ls -ld /home/venom/.matlab/R2022a

drwxr-xr-x 4 venom venom 20480 Aug 12 10:03 /home/venom/.matlab/R2022a


whoami                                                                                                                ─╯
venom

The filesystem is completely local. There are no other mounted filesystem, other than my boot drive.

Matlab runs under my own user account.

I can say that matlab has full acess to the preferneces folder, because some preferences do get saved. I can see that being updated in matlab.prf file under the preferences folder (keyboard shortcuts and antialias settings do get saved)

[jclds139]

I'm running into a similar problem. Once thing I did notice after running MATLAB in a clean Debian VM is that the affected preferences are saved to .mlsettings files, such as matlab.mlsettings and parallel.mlsettings.

Answer 1

[Dilip Parasu]

The issue was hard link error from /tmp folder to Matlab config directory. This happened because the /tmp folder did not belong to the root user, instead it was using tempfs

This can be prevented by masking tmp.mount service with

sudo systemctl status tmp.mount

​And removing the tempfs mount from /etc/fstab

After doing this, the Matlab preferences are being saved

[jclds139]

Generally you want your /tmp to be on a tmpfs. Also, if it's trying to hard-link, then this still wouldn't help in the common situation where /home is on a separate partition. I tried setting $TMPDIR, though, and that did work as a workaround without remounting /tmp.

This would definitely qualify as a bug, then, albeit apparently one with some obscure requirements. /tmp could be on any filesystem.

[Shervin Sahba]

Thanks for this tip. Fixed it for myself with the TMPDIR env variable route. I agree that's less brutal than shutting down the tmpfs. Here's the relevant post.