MATLAB Answers

Saving file over ssh not working

11 views (last 30 days)
bandabn009 on 19 Jan 2017
Edited: Patrick Cody on 2 Mar 2021
I have a remote folder mounted via ssh and gvfs and i am able to load and run the files in this folder within matlab. However i can't save the file, matlab only prints out
'Error writing file ... (Operation not supported)'.
With other programs like gedit I have no trouble saving the same files. Has someone an idea what could be the problem?
Patrick Cody
Patrick Cody on 2 Mar 2021
Same issue w/ Ubuntu 20.04 and MATLAB R2020b
User has full read and write permissions to drive mounted via SSHFS. Confirmed w/ bash / touch 'test.txt'.
Matlab is run as user.
When calling save in the sshfs mounted directory matlab throws a 'file may be corrupt' error and leaves an empty named file. Somehow matlab permissions may be different from user permissions?
EDIT: No issue w/ samba/CIFS, using that instead!

Sign in to comment.

Accepted Answer

Walter Roberson
Walter Roberson on 27 Jan 2017
This is something that can happen with filesystems when you have write access to the file but not to the directory. When you are overwriting files, there are multiple strategies that can be followed:
  1. delete the old file and write the new one. This fails if you do not have delete permission for the file, or if you do not have create permission in the directory. If something happens between the time of the delete and the time the new file is created, you can be left with no file at all. If something happens after the new file is created but before it is finished being written , you can end up with a partial file
  2. rename the old file and write a new one, and if failure, attempt to rename the old file back. Renaming the old file can fail if you do not have write permission in the directory, leading you not to write into a place you have access -- but at least in this case you do not lose anything. If there is a problem with the writing of the new file, it is possible that whatever the issue is will prevent you from renaming the old file back again. The new file might not be able to get the same permissions and ownership as the old file.
  3. write the new file into a temporary file on the destination file system, and when writing works successfully, rename the temporary to the name. This can fail if you do not have write permission to the directory. Glitches can lead to the temporary file being left in place. The new file might not be able to get the same permissions and ownership as the old file
  4. write the new file directly on top of the old file. Permissions and ownership are certain to be preserved. Failure during the write process can leave you will a corrupt file and no way to get back.
Different programs can choose different ones of these, with different potential consequences.
Remote filesystems find it more difficult to meet atomicity guarantees, so using a temporary file becomes more common -- but that introduces the kinds of permission problems that I discussed earlier.
It is also not rare to have a failure writing to a remote file, especially if the program doing the writing is doing a number of ioctl's or a number of fseek (such as might be needed to update an index at a fixed position in a file.)
It is typically faster and more robust to write to a local disk and then copy the local file to the remote system.
Walter Roberson
Walter Roberson on 28 Jan 2017
Also #5
  • copy the old file to a temporary file, and then write directly into the existing file, and if there is a problem then copy the temporary file back into the existing file. This can fail if you do not have file create permissions on the remote file system. This preserves permissions for the existing file. If the disk fills up during the write of the temporary file you are ok because you can delete it and abort with no loss. If the disk fills up during the write of new data into the existing file then you can only guarantee that you can put the old content back if the new content written is at least as big as the old (though you can use other strategies to reduce this problem), but at least in this case you can leave the backup file there (but it might not have the right ownership and permission to just rename back). Hmmm, thinking about it, this might be a useful strategy.
Good programs try not leave corrupted files around if the save fails, but not all of them handle the situation the same way, and a lot of programs do not even try.

Sign in to comment.

More Answers (1)

Samarth Shah
Samarth Shah on 26 Jan 2017
Hi Fabian,
Typically the User permissions of a folder is divided into Read and Write permissions. This is happening most likely because you do not have the write permission from the folder, however, you might have the read permissions.
  1 Comment
bandabn009 on 26 Jan 2017
Hey Samarth, I'm pretty sure this is not the case. As I wrote, with other programs I can save just fine (and I see that I have the permissions). It could only be that MATLAB does not have the rights my user has, but that would be very strange. So far I think it's a bug.

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by