Code Fails to Write to Folder that has Correct Write Permissions
32 views (last 30 days)
Show older comments
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.
7 Comments
Accepted Answer
Raymond Norris
on 11 Aug 2023
Moved: Walter Roberson
on 11 Aug 2023
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.
2 Comments
dpb
on 12 Aug 2023
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
More Answers (1)
Walter Roberson
on 31 Jul 2023
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.
2 Comments
See Also
Categories
Find more on Introduction to Installation and Licensing in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!