There is samba server with 4.2.13 sharing one directory: /mnt/storage-sdd-noraid/public drwxr-xr-x 8 arekm users 143 06-19 11:10 /mnt/storage-sdd-noraid/public samba config is simple: [global] workgroup = WORKGROUP server string = Samba Server hosts allow = 192.168. 127. load printers = no log file = /var/log/samba/log max log size = 50 security = user map to guest = Bad Password socket options = TCP_NODELAY domain master = yes preferred master = yes wins support = yes dns proxy = no use sendfile = yes unix extensions = yes delete readonly = yes ea support = yes [homes] comment = Home Directories browseable = no writable = yes [printers] comment = All Printers path = /var/spool/samba browseable = no guest ok = no writable = no printable = yes [storage-sdd-noraid] comment = storage sdd noraid path = /mnt/storage-sdd-noraid/public public = yes writable = yes force user = arekm There is a linux client (xps) mounting the share, from /proc/mounts: //192.168.1.1/storage-sdd-noraid on /mnt/storage-sdd-noraid type cifs (rw,relatime,vers=1.0,cache=strict,username=root,domain=ABC,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.1.1,unix,posixpaths,serverino,mapposix,acl,fsc,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1 and on client this directory looks like: drwxr-xr-x+ 8 arekm users 0 06-19 11:10 . [arekm@xps storage-sdd-noraid]$ ls -l x -rw-r--r--+ 1 arekm users 0 Jun 19 11:10 x [arekm@xps storage-sdd-noraid]$ rm x rm: cannot remove 'x': Permission denied so can't delete file from mounted share [arekm@xps storage-sdd-noraid]$ ls -ld . drwxr-xr-x+ 8 arekm users 0 Jun 19 11:10 . [arekm@xps storage-sdd-noraid]$ chmod g+w . [arekm@xps storage-sdd-noraid]$ rm x but if I change permission for group to be writable deleting works fine, touching also works fine [arekm@xps storage-sdd-noraid]$ touch x [arekm@xps storage-sdd-noraid]$ chmod g-w . [arekm@xps storage-sdd-noraid]$ rm x rm: cannot remove 'x': Permission denied [arekm@xps storage-sdd-noraid]$ touch y touch: cannot touch 'y': Permission denied [arekm@xps storage-sdd-noraid]$ Now that successful touched x file on server side looks like: -rw-r--r-- 1 arekm users 0 06-19 11:26 /mnt/storage-sdd-noraid/public/x so "force user = arekm" worked... Now why samba needs g+w on /mnt/storage-sdd-noraid/public? Makes no sense. "force user = arekm" should make u+rwX enough for file deletion/creation. I also straced smbd process when doing "rm x" on the client. smbd doesn't even try to do unlink(). It probably decided earlier that I have no permission... but it makes little sense to me. setresgid(-1, 1000, -1) = 0 getegid() = 1000 setresuid(1000, 1000, -1) = 0 geteuid() = 1000 lstat("x", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 getcwd("/mnt/storage-sdd-noraid/public", 4096) = 31 lstat("/mnt/storage-sdd-noraid/public/x", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 lstat("x", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 getxattr("x", "system.posix_acl_access", 0x7fff35a8ecf0, 132) = -1 ENODATA (No data available) stat("x", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 fcntl(26, F_SETLKW, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=388, l_len=1}) = 0 fcntl(26, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=388, l_len=1}) = 0 lstat("/var/run/samba/winbindd", 0x7fff35a8b590) = -1 ENOENT (No such file or directory) geteuid() = 1000 getegid() = 1000 getgroups(0, NULL) = 14 (note: user arekm on server and on the client - both have uid/gid == 1000/1000)
Can you please run smbd with log level 10 and attach the logs of a failed attempt? Thanks
Created attachment 12190 [details] smbd log Looks like interesting data is in this log. It's "touch zupa" in /mnt/storage-sdd-noraid mounted using linux cifs client. check_parent_access: access check on directory . for path zupa for mask 0x2 returned (0x2) NT_STATUS_ACCESS_DENIED but why? [arekm@serarm ~]$ ls -ld /mnt/storage-sdd-noraid/public/ drwxr-xr-x 8 arekm users 131 06-20 21:17 /mnt/storage-sdd-noraid/public/ [arekm@serarm ~]$ LC_ALL=C getfacl /mnt/storage-sdd-noraid/public/ getfacl: Removing leading '/' from absolute path names # file: mnt/storage-sdd-noraid/public/ # owner: arekm # group: users user::rwx group::r-x other::r-x
There is a wrong conversion happening of the uid 1000 in the posix acl. It should be translated to S-1-22-1-1000, but is translated to S-1-5-21-4285455791-229362118-3877793692-1000. As a result, the access checks fail. Are you running winbindd? Did you run winbindd in the past? Looks like you still have a mapping around in the caches from a previous, different setup. Those are valid for 7 days. Clearing the cache should fix it. Try net cache flush and recyling the client's connection.
winbind in my Linux distribution is in separate subpackage that I don't have installed (and didn't have in last weeks). No winbind.tdb, too: # pwd /var/lib/samba # LC_ALL=C ls -al total 6876 drwxr-xr-x 4 root root 4096 Jun 29 08:28 . drwxr-xr-x 44 root root 4096 May 15 18:56 .. -rw------- 1 root root 421888 Jun 19 00:28 account_policy.tdb -rw-r--r-- 1 root root 40200 Jun 20 21:22 brlock.tdb -rw-r--r-- 1 root root 383 Jan 18 2014 browse.dat -rw------- 1 root root 696 Jun 20 21:22 dbwrap_watchers.tdb -rw-r--r-- 1 root root 20480 Jun 29 08:28 gencache_notrans.tdb -rw------- 1 root root 77824 Oct 5 2011 group_mapping.ldb.replaced -rw------- 1 root root 696 Jun 19 00:28 group_mapping.tdb -rw-r--r-- 1 root root 696 Jun 20 21:22 leases.tdb -rw-r--r-- 1 root root 5361664 Jun 29 08:27 locking.tdb -rw-r--r-- 1 root root 7090 Apr 22 2013 namelist.debug -rw-r--r-- 1 root root 696 Jun 20 21:22 notify.tdb -rw-r--r-- 1 root root 696 Jun 20 21:22 notify_index.tdb drwxr-xr-x 2 root root 6 Oct 5 2011 perfmon -rw-r--r-- 1 root root 12288 Jun 29 08:19 printer_list.tdb drwxr-xr-x 2 root root 26 Jun 18 14:37 printing -rw------- 1 root root 528384 Jun 19 00:28 registry.tdb -rw-r--r-- 1 root root 8192 Jun 29 08:28 serverid.tdb -rw------- 1 root root 421888 Jun 19 00:28 share_info.tdb -rw------- 1 root root 28672 Jun 29 08:27 smbXsrv_open_global.tdb -rw------- 1 root root 32768 Jun 28 21:13 smbXsrv_session_global.tdb -rw------- 1 root root 16384 Jun 28 21:13 smbXsrv_tcon_global.tdb -rw------- 1 root root 16384 Jun 20 21:22 smbXsrv_version_global.tdb -rw-r--r-- 1 root root 311 Jun 29 08:28 wins.dat -rw------- 1 root root 8192 Jun 29 08:20 wins.tdb Is anything else creating these mappings? (anyway I think that recently deleting started to work again, so likely cache expired... will try more when I get back home)
not a bug, this is a configuration issue, wrong id mapping, please consult the mailing list for configuration help