Permissions problems with SAMBA under NETH8

Dear community,

I’m having strange problems with the permissions within my Samba shares (samba1) whenever files are created or edited from the host system, i.e., outside the container.

I can then open the edited files via the Samba shares, but I can’t delete them from there. The permissions are set exactly the same as those of the other files in the share – both from the NETH8 host and the container.

Background:
I use scripts to evaluate or edit files. These scripts usually run from the Nethserver(7/8) host. This wasn’t a problem under Nethserver7; the editing process either had to run in the correct context, or the files or folders had to be subsequently corrected regarding their ownership or permissions. This worked for years.

With Nethserver8, things are a little different now. There are ownerships and permissions as seen by the NETH8 host and those seen by the respective container. And of course, most actions should be performed from the container.

My scripts, however, should run from the NETH8 host, if only because they require tools such as Tesseract, etc., which I don’t want in the container. However, files are processed in the Samba container (/home/samba1/volume/etc./pp.).

For example, a PDF file is thrown into the share via the share, which is then processed by the script or tools and moved through various folders during the process. At the end, the processed files are available as desired – except that they cannot be deleted from the share.

Variant 1:
Processing runs in the context of the user “samba1,” who also creates folders in the share and creates and moves files within this share during the process. The original PDF file is also moved during the process. In the end, all files and folders have the same (correct) ownership (samba1/$ID). Only the permissions of the newly created files differ; the script then corrects this for the subfolder created by the script and recursively for the files as well using

chmod -R u+x,g+w /home/samba1/path/to/volume/and/to/share/with/subfolder/

However, the created files cannot be deleted from the Samba client (MacOS). The original PDF, however, can be deleted. All files are displayed as follows:

ls -al /home/samba1/path/to/volume/and/to/share/with/subfolder/

-rwxrw-r-- 1 samba1 $ID

Ownership and permissions are also displayed as identical in the container:

runagent -m samba1 podman exec samba-dc ls -al /srv/shares/share/with/subfolder

-rwxrw-r-- 1 root users

A comparison of different subfolders using

runagent -m samba1 podman exec samba-dc getfacl /srv/shares/share/other/subfolder

also shows no differences:

file: srv/shares//share/other/subfolder
owner: root
group: users
flags: -s-
user::rwx
group::rwx
other::r-x

As part of the troubleshooting, I tested variant 2:
Processing continues to run in the context of the user “samba1,” but the creation of folders and moving within the share is performed using

runagent -m samba1" podman exec samba-dc SOMECOMMAND

Here, too, the ownership of the created files and folders is correct in the end – both from the host and the container. Only the permissions of the newly created files and folders are slightly different:

drwxr-sr-x

instead of

of drwxrwsr-x

(both, from the host and the container).

So, the script finally corrects this to “chmod -R g+w” for the subfolder created by the script and recursively for the files as well.

But none of this makes a difference. The files and folders created in the script run cannot be deleted from the share (only tried on MacOS without AD connection). The ownership and permissions look identical.

What am I missing here?

Of course, I can delete them via the shell, but the created elements should be usable from the share.

Is there a special command that can be used to correct the corresponding permissions for specific folders? Using the GUI obviously doesn’t make sense in the context of my script.

Regards, Yummiweb

Could it be a Mac issue? Did you try the Mac customization?

You could copy the files using podman cp to keep the owner/permissions.

podman cp containername:/path myfile

Process myfile locally.

podman cp myfile containername:/path

Or you could use podman unshare which also keeps permissions:

runagent -m samba1

Edit a file as example:

podman unshare nano $(podman volume inspect shares --format={{.Mountpoint}})/share/file

Here’s how the permissions are resetted from the UI:

Thank you for trying to help me.

Unfortunately, I not only have to avoid copying files and editing them in the editor, but also rename them and have other tools (tesseract) read them and output new files.

This means I’m forced to perform actions from outside the container.

The example podman commands are of no use to me, because they only include podman commands.

I’ve now followed this command by command and found that the problem already occurs when creating a folder.
(i.e., not only when a file is being edited separately)

What works is renaming files (files can be deleted afterwards):

Renaming option 1 - using “sudo -u samba1”

sudo -u samba1 mv /home/samba1/hostpath/share/folder/myfolder/myfile1 /home/samba1/hostpath/share/folder/myfolder/myfile2

Renaming option 2 - using “runagent -m samba1 podman exec samba-dc”

runagent -m samba1 podman exec samba-dc mv /srv/shares/share/folder/myfolder/myfile1 /srv/shares/share/folder/myfolder/myfile2

In both options, the users/groups and permissions of the file are as follows:

Read from the host:

sudo -u samba1 ls -al /home/samba1/hostpath/share/folder/myfolder/myfile2

-rwxrw-r-- 1 samba1 $GID

Read from the container:

runagent -m samba1 podman exec samba-dc ls -al /srv/shares/share/folder/myfolder/myfile2

-rwxrw-r-- 1 root users

The moved files can be deleted from the SAMBA share, so there’s no problem up to this point.

Create folder:

Create folder option 1 - the “samba_folder” folder is created via the SAMBA share.

The folder’s users/groups and permissions are then as follows:

Read from the host:

drwxrwsr-x samba1 $GID

Read from the container:

drwxrwsr-x 1 root users

ACL read from the container:

owner: root
group: users
flags: -s-
user::rwx
group::rwx
other::r-x

The folder can be created and deleted from the SAMBA share, so everything is as expected.

However, if a folder is created from the host or the container, the problems begin:

Creating a folder: Option 2 - using “sudo -u samba1”

sudo -u samba1 mkdir /home/samba1/hostpath/share/folder/newfolder

The folder’s users/groups and permissions are then as follows:

Read from the host:

drwxr-sr-x samba1 $GID

Read from the container:

drwxr-sr-x root user

ACL read from the container:

owner: root
group: users
flags: -s-
user::rwx
group::r-x
other::r-x

We can see that the folder created this way lacks the “w” group permission.
(compared to the folder created via SAMBA share)

Creating a folder: Variant 3 - using “runagent -m samba1 podman exec samba-dc”

runagent -m samba1 podman exec samba-dc mkdir /srv/shares/share/folder/newfolder

Read from the host:

drwxr-sr-x 1 samba1 $GID

Read from the container:

drwxr-sr-x 1 root users

ACL read from the container:

owner: root
group: users
flags: -s-
user::rwx
group::r-x
other::r-x

We can see that the created folder is also missing the “w” group permission.
(compared to the folder created via SAMBA share)

Accordingly, these folders cannot be deleted from the share - that was to be expected.

Therefore, we will now attempt to correct the permissions of the folders created remotely, similar to the “samba_folder” folder created via Samba:

Correcting Permissions Option 1 - Folder created via “sudo -u samba1”:

sudo -u samba1 chmod g+w /home/samba1/hostpath/share/foldernewfolder

Result:

Read from the host:

drwxrwxr-x samba1 $GID

Read from the container:

drwxrwxr-x root users

ACL read from the container:

owner: root
group: users
user::rwx
group::rwx
other::r-x

The folder still cannot be deleted from the SAMBA share.
Well, it’s apparently still missing the bit for inheriting parent permissions.

So we’ll try to inherit the permissions from the parent folder:

sudo -u samba1 chmod --reference=/home/samba1/hostpath/share /home/samba1/hostpath/share/foldernewfolder

Permissions read from host:

drwxrwxr-x samba1 $GID

Permissions read from container:

drwxrwxr-x root user

ACL read from container:

owner: root
group: users
user::rwx
group::rwx
other::r-x

Since the chmod command was executed from the host, no ACL could be transferred from the container, right?

Accordingly, the folder still cannot be deleted from the SAMBA share.

Therefore:
Correct permissions. Option 2 - Folder created with “runagent -m samba1 podman exec samba-dc”:

runagent -m samba1 podman exec samba-dc chmod g+w /home/samba1/hostpath/share/folder/newfolder

Result:

Read from the host:
drwxrwsr-x samba1 $GID

Read from the container:
drwxrwsr-x root users

ACL read from the container:

owner: root
group: users
flags: -s-
user::rwx
group::rwx
other::r-x

This actually looks very good now.
Compared to the folder created via the SAMBA share, I can no longer detect any differences.

However, the folder cannot be deleted from the share.

Therefore, we will try to inherit the permissions from the parent folder. This time using:

runagent -m samba1 podman exec samba-dc chmod --reference=/home/samba1/hostpath/share/folder /home/samba1/hostpath/share/folder/newfolder

Result:

Read from the host:

drwxrwsr-x samba1 $GID

Read from the container:

drwxrwsr-x root users

ACL read from the container:

owner: root
group: users
flags: -s-
user::rwx
group::rwx
other::r-x

This also looks correct compared to the folder created via the SAMBA share.

However, the folder cannot be deleted from the share.

For comparison, here’s the folder created via the SAMBA share:

Read from the host:

drwxrwsr-x samba1 $GID

Read from the container:

drwxrwsr-x root users

ACL read from the container:

owner: root
group: users
flags: -s-
user::rwx
group::rwx
other::r-x

The folder created via the SAMBA share can be deleted from the share as usual.

What am I missing here? What special permissions are still missing?

Surely it must be possible to correct the permissions outside of the SAMBA share, without rewriting the entire share permissions?