Matlab can't save to Samba shared folder

I'm running a shared Samba folder (using a FreeNAS 9.3 box) for shared access to some experiment data. Unfortunately, Matlab seems to have big issues writing files on this share. The share is configured with the options

force create mode=0666
force directory mode = 0777

so that all files can be read or written by anyone. Now when I try to save a Matlab .MAT file it fails like so:

>> a = 5

a =

       5

>> save test
Error using save
Unable to write to MAT-file /mnt/share/signals/test.mat

File may be corrupt.

>> save test
Error using save
Unable to write file test: permission denied.

It should be noted that after the first save, a file names 'test.mat' appears in the shared folder which is empty:

$ ls -la test.mat
-rw-rw-rw- 1 nobody root 0 Oct  5 15:42 test.mat

As you can see even the permissions are correctly set to read/write for everyone so it is quite unclear to me whether this happens. Even more strangely, I can do the following:

>> f = fopen('test.mat', 'w');
>> fwrite(f, 'test123456');
>> fclose(f);
>> exit
$ cat test.mat
test123456

So apparently, the problem is not really permission denied or a corrupted file since, apparently, Matlab can write files just fine. So I'm wondering if anyone ever had this problem and has an idea on what the true cause is (or even how to find out) and how to fix this issue.

Answer 1

[derjan]

Well I probably have a bit of a special case going but I post my solution anyways. The shared folder was originally configured with Unix-Style ACLs and the above-mentioned force-modes to allow r/w-access for anyone. Creating a new Dataset with windows style ACLs and allowing full access for everyone like so

setfacl -m everyone@:rwxpDdaARWcCos:fd----:allow share-new/

and then creating a new windows share (without any force modes) basically restores the old behavior.

I'm not sure what Matlab tripped over, but the error message I got was not very helpful since every other program had no problems with the share as it was.

Answer 2

[Walter Roberson]

One thing I notice is that the test.mat created by save() ends up owned by root.

If you yourself are running as root then you are supposed to be denied write access as a security measure (to ensure that someone cannot simply make themselves root and clobber any file on the share.)

If you yourself are not running as root then old implementations sometimes had the bug of creating the file as root and then chown'ing it to you, but proper implementations of the samba daemon should fork off a process that operates as you and have that process create the file as otherwise there are race conditions that can be exploited.

It has the look to me that the file was created as root and then the chown failed and MATLAB detected that and ducked out of the save.

Your fopen()/fwrite() appears to have been against a test.mat that already existed and had write permissions rather than against a new file. It can be legal to write to a file you do not have permissions to create. save() against an existing file would, as a matter of good practice, want to write to a different file and move into place once the save is done, an operation that would could fail if you do not have permission to delete the original file (because you ended up not owning it.)

[derjan]

Good points. However, the root cause must have been something different. Looking at the situation currently:

>> a = 5

a =

       5

>> save test
>> exit
$ ls -la test.mat
-rwxrwxrwx 1 nobody root 171 Oct  6 10:45 test.mat

Access rights are the same as before, only now it is working using the other ACL scheme. Also, during the fopen/fwrite calls the files did not exist before.

[Rakshit Kothari]

Thanks. This helped me out. When accessing samba, do not use MATLAB in sudo.