I am running Samba 4.6 on FreeBSD 11 with ZFS. Each user belongs to the fileserver group. In addition, there are additional groups for each department, such as sales group.

And here comes my problem. On the server is a folder called sales. Which is owned by fileserver and the group sales. Why can't my group members from sales overwrite files via Windows inside this folder. Using a shell access the editing works without any problems.

Under Windows appears the message Access to the destination folder has been denied when I try to overwrite a file. New files can be created inside the sales folder without a problem. Renaming also works

folder sales
chmod 770 sales
chown fileserver:sales

# file: sales
# owner: fileserver
# group: sales

Inside the sales folder is a file test.txt

chmod 770 test.txt
chown fileserver:sales

# file: test.txt
# owner: fileserver
# group: sales

Changing the folder permissin to chmod 2770 sales has also no effect

Only if I give the file the same ACL rights as the owner the saving works. Why is that? Did I make a wrong setting? The group permission rights rwx should overule the ACL rights? No?

# Logging
log level = 3
log file = /var/log/samba4/log.%m
max log size = 50
utmp = 0

# Domain & controller & workgroups
server string = NAS Server
workgroup = COMPANY
server string = NAS
netbios name = NAS

# Network restriction
bind interfaces only = yes
interfaces = lo0 igb0

# Security model
security = user
encrypt passwords = true
map to guest = bad user

# Time server
time server = yes

map hidden = no
map system = no
map archive = no
map readonly = no

store dos attributes = yes

ea support = yes
access based share enum = yes
load printers = no

template homedir = /fileserver/users/%U
allow insecure wide links = yes

comment = Data
path = /fileserver/data
valid users = +fileserver

browsable = yes
writable = yes
read only = no
guest ok = no
public = no
follow symlinks = yes
wide links = yes

create mask = 0770
force create mode = 0760
directory mask = 2770
force directory mode = 2770

hide unreadable = yes

vfs objects = shadow_copy2 zfsacl recycle crossrename
shadow: snapdir = .zfs/snapshot
shadow: sort = desc
shadow: format = %Y-%m-%d-%H%M

recycle:directory_mode = 0750
recycle:subdir_mode = 0750
recycle:exclude = *.tmp *.temp *.swp
recycle:keeptree = yes
recycle:repository = Trash/%U
recycle:versions = yes
recycle:touch = yes
recycle:touch_mtime = yes

nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes

crossrename:sizelimit = 50
  • Please post the output of zfs get all <dataset> (replacing dataset with the correct ZFS filesystem). – shodanshok Nov 4 '17 at 20:40
  • zroot/fileserver aclmode passthrough local zroot/fileserver aclinherit passthrough local – Paul Atreides Nov 6 '17 at 8:37

So, you expect the read-write access to work without delete, delete_child and write_owner ? This is just wrong, you are not inside the legacy 3x3 POSIX permissions system, it's NFSv4 ACLs. They aren't additional to POSIX 3x3, they are normalized. Basically you need the full_set ACL, in you need more fine-grained control you need to experiment.

And don't forget that you alsi need the aclmode and aclinherit set to passthrough on this dataset.

  • zroot/fileserver aclmode passthrough local zroot/fileserver aclinherit passthrough local – Paul Atreides Nov 6 '17 at 8:27
  • As I mentioned above it works when I give the file the same rights as the owner which is rwxp--aARWcCos:-------:allow. There is only a write_owner permission not delete permission. – Paul Atreides Nov 6 '17 at 8:34
  • As I mentioned above, it’s not enough, and “works” cover a wide range of states as it’s very illusional verb: on one of it’s range of senses us a total failure, on the other - ultimately working solution. You probably need to start to read what you’re answered with. – drookie Nov 6 '17 at 9:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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