Saving file over ssh not working

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?

[Wilson González Vanegas]

I have exactly the same problem in Ubuntu 20.04 and MATLAB R2020a. Did you find any solution?

[Patrick Cody]

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!

Answer 1

[Walter Roberson]

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.

[bandabn009]

Thanks, this explains it pretty good. Seems I have to change my workflow.

[Walter Roberson]

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.

Answer 2

[Samarth Shah]

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.

[bandabn009]

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.