4

I've set a samba server that seems to work, all shares are seemingly exported as readonly, however. The machine is called "lx". When I'm on lx I can run the following command:

froh@lx:~$ smbclient //lx/export -UAdministrator 
Enter Administrator's password:  
Domain=[CUSTOMER] OS=[Unix] Server=[Samba 3.5.4] 
smb: \> mkdir wrzlbrmpf 
NT_STATUS_MEDIA_WRITE_PROTECTED making remote directory \wrzlbrmpf
smb: \> ls
  .                                   D        0  Fri Dec  3 19:04:20 2010
  ..                                  D        0  Sun Nov 28 01:32:37 2010
  zork                                D        0  Fri Dec  3 18:53:33 2010
  bar                                 D        0  Sun Nov 28 23:52:43 2010
  ork                                          1  Fri Dec  3 18:53:02 2010
  foo                                          1  Sun Nov 28 23:52:41 2010
  gaga                                D        0  Fri Dec  3 19:04:20 2010

How can I troubleshoot this?


What I did:

First I set up a fresh install of Ubuntu 10.10 x64.

Second I got kerberos working with the following krb5.conf file:

[libdefaults]
        ticket_lifetime = 24000
        clock_skew = 300
        default_realm = CUSTOMER.LOCAL

[realms]
    CUSTOMER.LOCAL = {
        kdc = SB4.customer.local:88
        admin_server = SB4.customer.local:464
        default_domain = CUSTOMER.LOCAL
    }


[domain_realm]
        .customer.local = CUSTOMER.LOCAL
        customer.local = CUSTOMER.LOCAL

#[login]
#       krb4_convert = true
#       krb4_get_tickets = false

I also added winbind to group, passwd and shadow in nsswitch.conf.

Seemingly Kerberos works:

root@lx:~# net ads testjoin Join is OK root@lx:~# wbinfo -a 'Administrator%MYSECRETPASSWORD' plaintext password authentication succeeded challenge/response password authentication succeeded

wbinfo -u and wbinfo -g also spit out a list of users and a list of groups respectiveley. I noted that domain accounts did NOT include a domain and they are in german (as on the SBS 2003 that is the domain server). So I get a "Domänenbenutzer" in wbinfo -u's output not a "CUSTOMER+Domain User" or something similar.

I'm not sure anymore what I did to the PAM configuration, but here is what I currently have:

root@lx:/etc/pam.d# cat samba 
@include common-auth
@include common-account
@include common-session-noninteractive
root@lx:/etc/pam.d# grep -ve '^#' common-auth 

auth    [success=3 default=ignore]      pam_krb5.so minimum_uid=1000
auth    [success=2 default=ignore]      pam_unix.so nullok_secure try_first_pass
auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
root@lx:/etc/pam.d# grep -ve '^#' common-account 

account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so 
account [success=1 new_authtok_reqd=done default=ignore]        pam_winbind.so 
account requisite                       pam_deny.so
account required                        pam_permit.so
account required                        pam_krb5.so minimum_uid=1000
root@lx:/etc/pam.d# grep -ve '^#' common-session-noninteractive 

session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session optional                        pam_krb5.so minimum_uid=1000
session required        pam_unix.so 
session optional                        pam_winbind.so 

At some point I joined the linux box into the AD domain.

After (manually) creating a home directory on the linux box I can log in using the Adminstrator user with the password taken from AD.

Now I run samba with the following setup:

[global]
        netbios name = LX
        realm = CUSTOMER.LOCAL
        workgroup = CUSTOMER
        security = ADS
        encrypt passwords = yes
        password server = 192.168.20.244     #IP des Domain Controllers
        os level = 0
        socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        winbind enum users = Yes
        winbind enum groups = Yes
        preferred master = no
        winbind separator = +
        dns proxy = no
        wins proxy = no
#       client NTLMv2 auth = Yes
        log level = 2
        logfile = /var/log/samba/log.smbd.%U
        template homedir = /home/%U
        template shell = /bin/bash

[export]
        path = /mnt/sdc1/export
        read only = No
        public = Yes

Currently I don't care whether export is exported to everyone or just one user, I want to see somebody WRITING to that directory before I start fiddling with the authentication settings. (Who may access it).

As mentioned, accessing the share from smbclient results in this NT_STATUS_MEDIA_WRITE_PROTECTED .

Accessing it from windows shows ACLs that look correct (The user may write) - but it does not work, I can only read files not write.

The directory to be exported looks like this:

root@lx:/etc/pam.d# ls -ld /mnt/
drwxr-xr-x 5 root root 4096 2010-11-28 01:29 /mnt/
root@lx:/etc/pam.d# ls -ld /mnt/sdc1/
drwxr-xr-x 4 froh froh 4096 2010-11-28 01:32 /mnt/sdc1/
root@lx:/etc/pam.d# ls -ld /mnt/sdc1/export/
drwxrwxrwx+ 5 administrator domänen-admins 4096 2010-12-03 19:04 /mnt/sdc1/export/
root@lx:/etc/pam.d# getfacl /mnt/
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: mnt/
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

root@lx:/etc/pam.d# getfacl /mnt/sdc1/
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: mnt/sdc1/
# owner: froh
# group: froh
user::rwx
group::r-x
other::r-x

root@lx:/etc/pam.d# getfacl /mnt/sdc1/export/
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: mnt/sdc1/export/
# owner: administrator
# group: domänen-admins
user::rwx
group::rwx
group:domänen-admins:rwx
mask::rwx
other::rwx
default:user::rwx
default:group::rwx
default:group:domänen-admins:rwx
default:mask::rwx
default:other::rwx

My, oh my what am I overlooking? What am I to blind to see?

froh42
  • 153
  • 1
  • 1
  • 7
  • Have you tried setting the writable setting to yes for your share? This is different from read only = no. – Matt Delves Dec 20 '10 at 04:27
  • Yes. Just to be sure I tried again and it makes no difference. I recall writable = yes to be a synonym for read only = no - and testparam seems to think similary. I've got a new hint - I made the share non-public and can not log in at all anymore. And googling for the warning I get from testparam with this configuration ("'winbind separator = +' might cause problems with group membership.") led me to some more hints I'm currently following: http://bit.ly/eKvJR0 (google) – froh42 Dec 20 '10 at 21:05

3 Answers3

12

I've just spent an incredible amount of time similarly debugging my server and have come down to the realization that the share and the directory being shared cannot have the same name.

I have no idea why. I hope someone else stumbles across this earlier in their process than I did.

Brandon
  • 136
  • 1
  • 3
  • Not sure why, but I can confirm this is the case (happened to me as well). – mboratko Feb 28 '15 at 21:15
  • 1
    It is ridiculous by I found exactly the same. If the share name and directory name are the same (and it isn't case sensitive), the share is read only. Once I changed the share names, my folders were writable. – Dolf Andringa Mar 28 '15 at 14:50
  • 2
    I created a bug for samba: https://bugzilla.samba.org/show_bug.cgi?id=13192 – hinneLinks Dec 15 '17 at 09:50
1

The share works correctly if it is called some OTHER name than "export". Very strage, this took me quite some time to figure out. So if I share it as "exportt" (dobule-t) it is read-write, if I share it as "export" it is read-only.

One question remains, is "export" some magical share name?

froh42
  • 153
  • 1
  • 1
  • 7
0

I've also documented that the Share name and Directory name cannot be the same or the share will be visible and read-only despite the permissions. When the Share name is modified to be different than the Directory (or Disk) name it will become writeable assuming it and the user have the correct permissions.

I found this with NTFS disks and folders mounted in Ubuntu that had been previously shared under NTFS using the same Share names. Win and Linux sharing tools both default to the directory or disk name for their share name during creation so the conflict is built-in by default. Simply adding a character to the Linux Share name made it writeable.

This may or may not be true if the disk or directory are not NTFS or are NTFS but have never been shared. It appears that previously-used NTFS share names are reserved when mounted in Ubuntu and Linux deals with the conflict by making the share read-only.

An NTFS directory share named \My Music simply renamed \My Muzak in Ubuntu is enough to make the directory writeable.