0

I have a Samba server based on Ubuntu 18.04, accessed by Windows 10 machines. There are several regular users and one admin user in the office. Since I want to keep the folder structure and prevent users from accidentally deleting or moving folders, the permission of the root folder is set to 750, so that only the owner (admin user) can change the directory structure.

This worked as long as the Samba server was running standalone (Ubuntu 16.04). I recently upgraded to 18.04 and now the Samba server is running as primary domain controller (PDC), which means that the extended attributes (acl_xattr) are enabled by default and cannot be disabled.

Since the migration to Samba as PDC with forced acl_xattr, something weird happens: Regular users still cannot create folders, this has to be done by the admin user. However, regular users can delete folders, even though the access rights of the parent folder is still set correctly to 750:

drwxr-x--- 30 admin_user user_group   4096 Jan  2 11:45 data

I am quite puzzled, since with these access rights, it should not be possible to delete anything from within this folder, except for admin_user and root. I suspect Samba to somehow overriding the missing write access when trying to delete things, but I failed in debugging this. What am I missing?

PS: Here is the definition of the share in my smb.conf

[Data]
   comment = Data
   path = /srv/data

   browseable = yes 
   writeable = yes 
   create mask = 0770
   directory mask = 0770
   force create mode = 0770
   force directory mode = 0770
   force group = user_group

   hide files = /?esktop.ini/?umbs.db/

   guest ok = no
   wide links = yes

Update 2020-01-05:

Here is the [global] part of my smb.conf. The setup was done with Zentyal.

[global]
    workgroup = company
    realm = COMPANY.LAN
    netbios name = server_name
    server string = Zentyal Server
    server role = dc
    server role check:inhibit = yes
    server services = -dns
    server signing = auto
    dsdb:schema update allowed = yes
    ldap server require strong auth = no
    drs:max object sync = 1200

    idmap_ldb:use rfc2307 = yes

    winbind enum users = yes
    winbind enum groups = yes
    template shell = /bin/bash
    template homedir = /home/%U

    rpc server dynamic port range = 49152-65535

    interfaces = lo,eth0
    bind interfaces only = yes

    map to guest = Bad User

    unix extensions = no

2 Answers 2

1

Care to share your [global] part of your smb.conf ? This would confirm if you are running a PDC or an AD DC and if you have added any lines you shouldn't have.

If it is an AD DC, then your share should just be this:

[Data]
comment = Data
path = /srv/data
read only = no

You then set the ACLs from Windows. NOTE: We do not recommend using a Samba AD DC as a fileserver, but if you do, you must follow the rules.

5
  • Who's "we" in the recommendation part? Jan 3, 2020 at 15:56
  • Ah, perhaps I should have said 'I', but it means 'Samba Team' Jan 3, 2020 at 17:21
  • Touché. This server is running in a small office. I didn't want to deploy several hardware servers for such a small setup.
    – Edgar
    Jan 5, 2020 at 14:37
  • @RowlandPenny, any hints on whether there is something odd with the [global] part of my smb.conf would be very much appreciated!
    – Edgar
    Jan 6, 2020 at 20:37
  • So, I finally had the chance to try this. I removed all the permission lines from my smb.conf and tried to set the ACLs from Windows as I wanted them to be. However, the actual behavior didn't change: The only way to prevent the deletion of a folder is to remove the write access on that folder explicitly. But then the creation of files in the folder is prevented, which means the people cannot even open an Office file. It really seems like Samba is only respecting the missing parent folder write permission for creation, but not for deletion of folder content. Is this intended? Is this a bug?
    – Edgar
    Jan 10, 2020 at 22:53
0

So, after almost a year, this question reached a thousand views. Since no additional answers came in, I'll quickly post my solution here, maybe it helps someone.

It looks like it is impossible to configure Samba folders like that. The reason probably is that Samba tries to replicate as closely as possible what Windows is doing, and, indeed, Windows allows folders to be deleted if the user either has the right to delete on the files in the folder or or the right to delete from the parent folder. Since Unix doesn't make a difference between writing and deleting, the users who can write can also delete.

I built myself a workaround: I configured the base directory to 750, so that only the admin can create new folders. New subfolders get 770 via Samba. I prevent deletion of the subfolders with chattr +a (the append flag), so that users cannot delete folders. That's already okay-ish (prevents deletion), but now only a Linux admin can delete or move folders.

In order for "regular" Samba admins to be allowed to delete or rename subfolders, I created a bit of magic (/root/lock_directory):

#!/bin/bash

folder=$1
attr=$(lsattr -d "$folder")
if [ -d "$folder/New Folder" ]; then
  if [ "${attr:5:1}" = "a" ]; then
    echo "Unlocking folder $folder"
    chattr -a "$folder"
  fi
fi
if [ ! -d "$folder/New Folder" ]; then
  if [ "${attr:5:1}" = "-" ]; then
    echo "Locking folder $folder"
    chattr +a "$folder"
  fi
fi

This script unlocks the directory when the admin has created a new folder (named "New Folder" by Windows' default). As long as the "New Folder" is there, the admin can do stuff (and users can delete subfolders accidentally). Once the admin deletes the "New Folder", the base directory is locked again.

Now in order to do this automatically, I use incron, and this is what my /etc/incron.d/incrontab looks like:

/srv/data IN_CREATE,IN_DELETE /root/lock_directory "/srv/data"

This automatically runs the lock/unlock script whenever a file is created or deleted in my base directory. I think that's as close as you can get.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .