2014-11-13 09:58 PM
Ok, hello everyone. So I've got a StoreVault, it works great, and for the most part it is wonderful. It has an issue that I'm not making headway on. I've got Linux clients and Windows clients, the Linux clients mount things via NFS the Windows clients, CIFS. When I change or update a file from the Windows client, the file becomes inaccessible (permission denied) from the Linux client. I can mount the file system from my root authorized machine, manually do a chmod to 640 and then alls good unless I write it from Windows at which point it gets screwed up again.
Players - Filer is a Storevault running DoT 7.2.1S1
Windows Clients are running Windows 7 Pro & Ultimate
Linux clients and servers running Ubuntu 14LTS.
The whole 'manage your filer' tool isn't too useful in Win7. However the console on the filer works fine. So what do I need to provide to figure out how to fix this? And no, I don't have an Active Directory running anywhere.
I'd love to fix this.
2014-11-17 02:03 AM
Are you using mixed security style for your volumes?
"qtree status" command would display this information.
Also, check the output of "fsecurity show /vol/volumename" to check what is the configured and effective security style of the volume.
If it is mixed, I would recommend changing it to either UNIX or NTFS and then creating a proper usermap.cfg file to map windows-unix accounts.
2014-11-17 08:54 AM
So that gets us closer, yes the volumes having issues are all 'mixed'. DOS attributes on a one are 0x0010 (-----D---) and the other are 0x0011 (----D--R). So if I set them to unix what usermap.cfg setting should I have ? I've currently got *\cmcmanis => cmcmanis for example in there to make any NT/Windows username for cmcmanis to map to my unix id of cmcmanis.
2014-11-20 10:26 PM
The usermapping should be fine in that case, I hope. By default, if no usermapping is in place, the system will try to map "userX" windows user to "userX" unix user and vice versa. Meaning it will consider identical windows and unix usernames as synonyms unless you explicitly specify a different mapping.
So, next thing what you need to do is changing the security style to unix. (unless you specifically want NTFS style permissions on these files).
Set this by "qtree security /vol/volname/qtreename unix" and you should be good to go.
If you think you may want to revert to old settings later, take a snapshot of the volume before running this command..!