Code Fails to Write to Folder that has Correct Write Permissions

This question is a follow-up to the one answered by @Walter Roberson here:

https://www.mathworks.com/matlabcentral/answers/2001572-matlab-won-t-run-a-code-even-when-in-directory-containing-the-code

The code that was having an issue running is supposed to write to a file. It throws an error when trying to write. If the file is in another directory (not a Matlab code directory) it works fine. The codes ought to be in the Matlab directory, so I need it to work where it is. Here is the error message:

Failed to open file /nfs/site/home/pasafier/.matlab/3p_cluster_jobs/R2022a/Job13/task.conf for writing

Is there an issue with a code in this type of directory writing files? I have permissions to write to the folder it is trying to write to. The code is here: /nfs/site/eda/data/eda_0037/mathworks/matlab/R2022a/common/toolbox/parallel/user/ which is where all the Matlab executables are.

Thanks for any advice.

[dpb]

I'm not surprised if you've trying to write to a location containing the MATLAB/TMW-supplied code. I think those are protected by TMW after install...

I gather you're not on Windows, but MS has gotten very beligerent about allowing any modifications to folders containing installed executables; run into the problem even with programs that have their own data files there if ever need to change...I have one vendor supplied accounting code that uses business tax schedules -- they can be edited to add additional or change to match revised rules by a text editor. That used to be trivial; now it's a real pain to bypass the OS security placed on the folder to do so...it can manage to be done, but it's a nontrivial exercise. Wouldn't be surprised if Linux now has something similar going on...

What are you trying to write to the code folder, anyway...user MATLAB code is generally run from a working directory and that should never be part of the distribution.

[Paul Safier]

Hi @dpb, the write is not to a location with the Matlab code. I am trying to write to an ordinary path in a directory I own. @Raymond Norris do you know what's going on?

[dpb]

OK, your last comment confused my reading, sorry.

It's been ages since I've used NFS, too, to the point hadn't even thought about @Walter Roberson's points until reminded; have you tried using his workaround (write local, then synch)?

[DGM]

I second that. NFS can cause a lot of unexpected problems, even on a local network if you're dealing with marginal wireless links. It's worth looking into.

[Image Analyst]

Let's make it clear and explicit: What operating system are you using?

I doubt it's Windows because the file name is "/nfs/site/home/pasafier/.matlab/3p_cluster_jobs/R2022a/Job13/task.conf" and it it were Windows, you'd have the drive letter first, before the first /.

Check the system properties of the file, if it already exists. Make sure the readonly flag is not set. Same for the folder "/nfs/site/home/pasafier/.matlab/3p_cluster_jobs/R2022a/Job13/" -- make sure the readonly property is not set on that folder, or any folders above it.

Anyway, don't forget to scroll down and see @Walter Roberson's Answer below.

[Paul Safier]

Hi @Image Analyst. This post, and the related post I linked, is referring to a Linux system.

To be clear on a couple of other items:

1. The executable Matlab code resides in the directories that normally house Matlab files. @Walter Roberson 's and @Raymond Norris 's comments about using rehash command allowed my code to be run.
2. The code tries to create a directory (e.g. Job13) that does not previously exist and a file within /Job13 called task.conf. The location is not within the Matlab source code area, but a directory that I own.
3. The permissions on R2022a are:

drwxrwxr-x 2 pasafier intelall 4.0K Jul 31 12:44 R2022a

4. We have another unrelated NFS system where this all works fine.

I will review Walter's information in the AM. Thanks.

[dpb]

We'll be interested to hear what you discover...

Answer 1

[Raymond Norris]

The issue turned out to be related to a symlink. Paul was pointing to a folder in his home directory that was symbolically linked elsewhere and MATLAB wasn't chasing through it, hence the

Failed to open file ...

Oddly, this wasn't an issue for his other system (similar setup), which is why it was expected to work on the second system. Problem was (sort of) resolved by removing the symlink. I'll look into why and if we can at least provide better error handling.

[Paul Safier]

Thanks for your help with this @Raymond Norris and thanks to everyone else for their suggestions and ideas.

[dpb]

Ah-so!. That's nice to have the feedback and know another thing to suspect, @Raymond Norris if/when somebody else were to see similar symptom

Answer 2

[Walter Roberson]

MATLAB itself does not act to specially protect files or directories, other than the initial setting of read/write/execute permissions at installation time. If a sufficiently authorized user were to set directory or file permissions to allow random users to change files, then MATLAB itself will make no attempt to protect against that.

However, to save resources, MATLAB does not monitor its toolbox directory and sub-directories looking for file changes (to detect changes to files that have already been parsed, to know to re-parse them or to update the user's edit sessions). To tell MATLAB to look inside its toolbox directory for possible file changes, the rehash command must be used.

On MS Windows systems, MATLAB installs in directories that are protected by Windows itself, not by MATLAB.

So, on Mac and Linux systems, if you have write access to a directory as far as the operating system is concerned, and also have write access... then MATLAB is not going to stop you from writing to the file. (Depending on which file is involved, it might use a cached version of the file until you tell it to check for updates.)

If a linux system is installed you might want to use getfacl https://www.redhat.com/sysadmin/linux-access-control-lists to check for Access Control Lists. If MacOS is installed you might want to use the e flag to ls to check for Access Control Lists https://ahaack.net/technology/OS-X-Access-Control-Lists-ACL.html -- and possibly also the @ flag to ls to check for xattr (because: gatekeeper -- and see https://eclecticlight.co/2023/03/13/ventura-has-changed-app-quarantine-with-a-new-xattr/ for more quarantine complications)

You are using NFS shared filesystems. It has been several decades since I last used NFS, so I no longer recall clearly how permissions and xattr and access control lists interact across mixed operating systems. Last I recall for NFSv2, if your local system does not allow you access to the appropriate mount point, then you simply cannot talk to the server about a file, but that once you have access through the mount point, that the server has control over access.

But... especially for NFSv2... NFS can simply be unstable, especially with respect to remote files (where the latency adds up or where packets traveling over a backbone are more likely to be lost.) It is not rare for NFSv2 to randomly deny write access to a file. I understand that NFSv3 is more stable that way; I do not have any experience with NFSv4. But back in the NFSv2 days, the truism was that it was a lot more stable and predictable to do all writing to local files and then to copy or rsync the results to the NFS mount point.

[Paul Safier]

We have one NFS system where the code works perfectly. We need it to run in a different NFS system, which is the one I am writing about. I do not know what NFS version they each are, but I can ask my network admins. I also need to find a way to determine (other than the NFS version) what could be different about the NFS system where the software works and the one where it doesn't. As far as simple folder permissions goes, there is no difference...

[dpb]

You could try <nfsstat>. I do at least recall one thing from lo! those many years ago! (A Foxboro IA (Intelligent Automation) control system ran Solaris and used NFS).