Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Very strange issue...

Samba share on remote:

[javaerpm]
    path = /u/abas/erpm/java
    force user = erpm
    guest ok = yes
    read only = no
    writeable = yes

Mount command on local using root:

root@crunchbang:/mnt/abas# mount -t cifs -o username=guest,rw,exec,auto //10.0.0.2/javaerpm ./javaerpm

Root can read/write/cd no problem at all:

root@crunchbang:/mnt/abas# cd javaerpm
root@crunchbang:/mnt/abas/javaerpm# touch test
root@crunchbang:/mnt/abas/javaerpm# ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test
root@crunchbang:/mnt/abas/javaerpm# rm test

But if I switch to a regular user and do the same thing I get this:

shawn@crunchbang:/mnt/abas/javaerpm$ touch test
touch: cannot touch `test': Permission denied

I can ll and I can see that it wrote the file anyways:

shawn@crunchbang:/mnt/abas/javaerpm$ ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test

I can even rm no problem:

shawn@crunchbang:/mnt/abas/javaerpm$ rm test
shawn@crunchbang:/mnt/abas/javaerpm$

I've tried different mounting options. uid=501 doesn't change anything. Tried nounix but then it doesn't work at all and I see nothing using root or shawn user.

share|improve this question
    
This Q looks to be the almost exact same issue: unix.stackexchange.com/questions/71896/…. –  slm Sep 25 '13 at 8:13
    
Not exactly the same issue. –  shrimpwagon Sep 26 '13 at 15:40
    
I said almost 8-). That comment was more directed to me linking common threaded Q's and A's together for future vistors, but thought you might check it out. –  slm Sep 26 '13 at 15:41
    
Oh, sorry, right, thank you. –  shrimpwagon Sep 26 '13 at 15:43

1 Answer 1

up vote 3 down vote accepted

Note: I'm just guessing here, I'm not a samba guru.

Samba/CIFS, at least the way you're using it here, does not reproduce credentials between the server and the client. Because of the force user directive on the server, all operations are performed as the user erpm on the server. However, because both the client and the server are running a unix system, they auto-negociated the CIFS POSIX extensions. This makes unix permissions appear to work up to a point, but only as far as the server permits, and you've run into a case where what the unix permissions claim and what the server allows differ.

You'll notice that all files appear as user ID 501. That's their uid on the server.

When you try to create or remove a file, this requires write permission on the directory. All access are mapped to a single user on the server, so write permission boils down to whether erpm is allowed to write to that directory on the server. The answer is yes.

When you run touch, it creates the file and then changes its modification time. Changing the modification time of a file requires ownership, and this is tested by the generic filesystem code, on the client side.

If you run strace touch test, you'll notice that then open call (which creates the file) succeeds, then the utimes call (or rather on Linux the utimensat system call) fails to set the times.

This is actually a bit weird because utimes should succeed, since touch calls it with a NULL argument (meaning “set the timestamp to the current time”), and this is supposed to be permitted to any caller that may write to the file, and not only to the owner like setting an arbitrary timestamp. I suspect that utimensat is actually doing a permissions-based check, and determining that the permissions say you can't write to that file, even though the filesystem would allow a write operation regardless of the actual permissions.

The main advantage of the CIFS POSIX extensions when the server side is running with the permissions of a non-root user are to carry over the executable bit, and possibly group ownership. It may be less confusing if you map user ownership to a single client-side user with the forceuid mount option.

share|improve this answer
    
Thank you so much for the thorough response. I eventually tried username=guest,defaults,noperm and that totally fixed the issue. I don't know what answer to accept on this one since username=guest,defaults,noperm probably isn't the best answer and I just don't have more time to try out your answer. Thank you again! –  shrimpwagon Sep 26 '13 at 15:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.