cifs mount unreliable

[romano r]

Hello,

I mount on my RHEL6 VMware machine a share from a windows server. This is the entry in the fstab:

server:share /mount_point cifs rw,uid=user1,gid=group1,file_mode=0664,dir_mode=0775,credentials=/etc/cred_xx.cifs 0 0

I've a job that after a copy of a directory from win to ux removes the win directory (It does this for some hundred of dirs with an average size of 10k).

Unfortunately during the removing phase for some directories I get a deleting error e.g.:

rm: cannot remove `7622611/MMC_files/boardlst.dat': Permission denied
rm: cannot remove `7622611/MMC_files/cop5_304.bin': Permission denied
rm: cannot remove `7622611/MMC_files/cph3_303.bin': Permission denied
rm: cannot remove `7622611/MMC_files/MMC_README.txt': Permission denied
rm: cannot remove `7622611/MMC_files/sdc5_301.bin': Permission denied
rm: cannot remove `7622611/MMC_files': Permission denied
rm: cannot remove `7622611/MMC_files': Permission denied 

When I look at the dir files have been removed, the permissions are 775 of dir and subdir.

If I try to remove the directory I get the same error unless I change the permissions (e.g.: chmod -R 775 7622611).

I guess it could be some sort of file locking or latency that locks the file.

Have someone some suggestion to arrange this?

Thank you

bye

Romano

[Matti_Kurkela]

It could be file locking, but it also could be Windows file/directory ACLs.

Remember: on cifs-mounted Windows shares, the file and directory permissions you see on the Linux client are created by your mount options (uid=user1,gid=group1,file_mode=0664,dir_mode=0775). These are enforced by the Linux client. Any operation you make can be restricted further by the Windows ACLs, which are enforced by the Windows server that provides the share, according to the Windows user you specified in your /etc/cred_xx.cifs file.

When you do a "chmod -R 775" on your problematic directories, the operation is probably applied as an ACL modification on the Windows server. Since the actual Windows ACLs cannot be directly mapped to POSIX ACLs, the getfacl/setfacl commands may or may not work, and would also be seeing a translated version of the true Windows ACL, and some information may be lost in the translation.

You should use a Windows system to view the true Windows ACL on one of the directories you fail to remove, and think in terms of "can the user specified in my cred_xx.cifs remove this directory?" If the answer is no, you've found the problem: the solution would then be to apply an ACL that a) allows your cred_xx.cifs user to read and remove anything, and b) is inherited by all files and directories placed into the share.