Suse 10.2 CIFS permissions problem
 

I have just upgraded Suse 10.0 to 10.2
10.2 uses CIFS, and SMBF seems to be deprecated.
Our networked Linux file server runs Samba. When I mount a Samba share that has restricted permissions, the share has a "lock" icon visible in Konqueror. the same share was perfectly accessible with my same credentials in /etc/fstab with Suse 10.0. Using the same credentials in 10.2 however, I cannot access the restricted shares. The shares are mounted OK though. All other shares which do not have the same permission restrictions, work fine, and I can read, write and execute in those.

Any ideas as to how to solve this would be greatly appreciated.

The /etc/fstab entry looks like this:

//192.168.1.9/** /home/bert-berlin/** cifs rw,username=*******,password=******,file_mode=0777,dir_mode=0777,uid=1000,gid=100

bert

Hi,

it's not clear for me why you give arguments like "file_mode" and "dir_mode". These options should be set on server side in /etc/samba/smb.conf

Dis you check the file system permissions? I had often the problem I could not access a samba share, configured by samba a thousand times, and the local directory and file permissions were not set propper.

Greets

Shaddy


P.S. Why did you give your password as argument in fstab? That is very unsafe :-) I think there a better solutions where you can write a hash of your password to an external file, which can be named at mount time. Look at smbpasswd

noperm option fixes permissions check problem in Suse 10.2
 

Just to close this - I added the option noperm to the entry in fstab, such as . . . rw,noperm,etc
and removed unnecessary part,e.g. file_mode=0777,dir_mode=0777,uid=1000,gid=100 0 0

The line now reads:
//192.168.1.9/it /home/bert-berlin/it cifs rw,noperm,username=bert-berlin,password=****

Since I am not concerned about theft of my password on our Company network, there is no reason to use Shaddy's suggestion for protecting the password.

The addition of noperm seems to prevent the Suse client from doing unnecessary permissions check (which fails). The server side remains unchanged (it is properly managed by an IT specialist).