Problem
Rename or deleting from files and subdirectories are not possible in a network share. A teacher tried to rename a directory which is located one level below “Lernmaterial” via a joined Windows Client.
The error shown in the Windows Explorer in german: “Die Aktion kann nicht abgeschlossen werden, da der Ordner (oder eine Datei darin) in einem anderen Programm geöffnet ist.
Schließen Sie den Ordner und wiederholen Sie den Vorgang.”
The error shown in the Windows Explorer in english: “The action cannot be completed because the folder (or a file in it) is open in another program.
Close the folder and repeat the operation.”
Environment
Found on UCS: 4.4-9 errata1227, ucsschool=4.4 v9
Workaround / Solution
The customer uses the “Cool Solution - Automatic creation of write/read-only folders in class/workgroup shares” which causes the problem. At the moment is not a real fix available, but a workaround can be used. The root users can do the necessary changes via SSH.
More details about the Cool Solution are described in the help article:
https://help.univention.com/t/cool-solution-automatic-creation-of-write-read-only-folders-in-class-workgroup-shares/12319
The script “univention-ro-wo-group-dirs.py” from the Cool Solutions sets a sticky bit on the distribution directory (default: Lehrmaterial). The owner is set to root. With root as owner and the sticky bit set it is only possible to delete or rename files or directories below the directory with this given permission only for root and nobody else then root.
The “T” is the sticky bit:
Investigation
The problem is found on the directory “Lernmaterial” and this is created from the univention-ro-wo-group-dirs.py script which runs triggered by a cronjob.
The cronjob itself is located in /etc/cron.d/univention-ucr-cronjobs
It is described in the crontab-file as:
# Create Abgabe and Lehrmaterial directories in class and workgroup shares
MAILTO=root
0 9,12,15,18 * * * root ps aux | grep "univention-ro-wo-group-dirs.py" | grep -v grep; if [ $? -eq 1 ]; then /usr/bin/univention-ro-wo-group-dirs.py; fi
By default the directory is called “Lernmaterial”, but it is adjustable with a ucr variable.
To get the momentary configured name, use this command:
ucr get group-dirs/ro/name
The so called distribution directory (by default “Lernmaterial”) created from the script has the following unix permissions:
drwxrwx--T+
The sticky bit is set by the script as a set of permissions, thats the reason only the owner or root can delete or rename files or directories located below the directory where the sticky bit is set.
The directory is set as owner: root and group as: lehrer-<group> from the script.
This means only root itself is able from the unix permission side to delete or rename files or directories, this reflects then also at the end to the Windows user that tries to rename or delete something below the sticky bit tagged directory.
First Samba was under suspicion and later the unix permissions was found as root cause for the problem.
While the customer reproduced the error the only relating thing that could be found in the log also with increased log level to debug 10 is:
[2022/09/27 09:17:21.543629, 1, pid=12345] ../../source3/smbd/vfs.c:895(vfs_GetWd)
vfs_GetWd: couldn't stat "." error Keine Berechtigung (NFS problem ?)
[2022/09/27 09:17:22.063110, 1, pid=12345] ../../source3/smbd/vfs.c:895(vfs_GetWd)
vfs_GetWd: couldn't stat "." error Keine Berechtigung (NFS problem ?)
[2022/09/27 09:17:22.575032, 1, pid=12345] ../../source3/smbd/vfs.c:895(vfs_GetWd)
vfs_GetWd: couldn't stat "." error Keine Berechtigung (NFS problem ?)
[2022/09/27 09:17:22.601656, 1, pid=12345] ../../source3/smbd/vfs.c:895(vfs_GetWd)
vfs_GetWd: couldn't stat "." error Keine Berechtigung (NFS problem ?)
[2022/09/27 09:17:36.496283, 0, pid=12345] ../../source3/smbd/uid.c:448(change_to_user_internal)
change_to_user_internal: chdir_current_service() failed!
To get out the most information that samba could provide we did the following:
cp -r /var/log/samba samba.0smbcontrol all debug 10- Reproduction at the share at Windows Explorer or “smclient” with “rename”.
cp -r /var/log/samba samba.1smbcontrol all debug 0diff -Nuar samba.0 samba.1 > diff01
The smblient test was done with the following steps (everything in <> must be replaced with real data):
- Login as root
samba-tool domain exportkeytab <username>.tab --principal=<username>@<domain>kinit -t <username>.tab <username>smbclient -k //$(hostname -f)/<share-name> -U <username>
The commands was done within the smbclient:
dircd Lernmaterial\rename test test2
The error occurs:
NT_STATUS_ACCESS_DENIED renaming files \Lernmaterial\test\ -> \Lernmaterial\test2
It was also tested if every permission level is correct:
Samba ACLs on the distribution directory:
smbcacls -U Administrator //$(hostname -f)/<share-name> "Lernmaterial/
→ example output with generic names:
REVISION:1
CONTROL:SR|DP
OWNER:Unix User+root
GROUP:DOMAIN+lehrer-domainname
ACL:Unix User+root:ALLOWED/OI|CI/FULL
ACL:DOMAIN+domainname-test:ALLOWED/OI|CI/READ
ACL:DOMAIN+lehrer-domainname:ALLOWED/OI|CI/FULL
ACL:Everyone:ALLOWED/OI|CI/
ACL:Unix User+root:ALLOWED/0x0/FULL
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO/FULL
ACL:DOMAIN+lehrer-domainname:ALLOWED/0x0/
ACL:CREATOR GROUP:ALLOWED/OI|CI|IO/
Samba ACLs on the sub-directory:
smbcacls -U Administrator //$(hostname -f)/<share-name> "Lernmaterial/test
→ example output with generic names:
REVISION:1
CONTROL:SR|DP
OWNER:Unix User+root
GROUP:DOMAIN+lehrer-domainname
ACL:Unix User+root:ALLOWED/OI|CI/FULL
ACL:DOMAIN+domainname-test:ALLOWED/OI|CI/READ
ACL:DOMAIN+lehrer-domainname:ALLOWED/OI|CI/FULL
ACL:Everyone:ALLOWED/OI|CI/
ACL:Unix User+root:ALLOWED/0x0/FULL
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO/FULL
ACL:DOMAIN+lehrer-domainname:ALLOWED/0x0/
ACL:CREATOR GROUP:ALLOWED/OI|CI|IO/
NT ACLs on the distribution directory:
univention-ldapsearch -LLL cn=<group> sambaSID
→ The command reads out the SID of the group
samba-tool ntacl get /home/<domain>/groups/<share-name>/Lernmaterial/ --as-sddl
→ We can check if the SID is set for the distribution directory
NT ACLs on the sub-directory:
samba-tool ntacl get /home/<domain>/groups/<share-name>/Lernmaterial/test/ --as-sd
→ We can check if the SID is set for the distribution sub-directory. The same SID should be used as we got from the univention-ldapsearch command
Check the permissions on SMB file shares:
sharesec <share-name> -v --view-all
→ example output:
REVISION:1
CONTROL:SR|DP
OWNER:
GROUP:
ACL:S-1-1-0:ALLOWED/0x0/FULL
Check for open file handles on the main directory from the share:
lsof /home/<domain>/groups/<share-name>
→ Nothing should come back from the command
Check for open file handles on the sub-directories:
lsof /home/<domain>/groups/<share-name>/*
→ Nothing should come back from the command
Does show smbstatus any allocated shares:
smbstatus -S | grep <share-name>
→ Empty table should be shown as below:
Service pid Machine Connected at Encryption Signing
---------------------------------------------------------------------------------------------
All the above commands to analyse the permission levels could be used in other cases where it not directly belongs to this root-cause what is described in this article.