Access denied creating new share under ns8 Shared Folders/Samba

Support
,
1

NethServer Version: NethServer 8
Module: samba->Shared Folders
Hi,
I have a little glitch with samba under ns8. I used to be able to create folders using the shared folder option, but now I get a permission denied error. As I haven’t delved into the backend I’m unsure what would have caused this. I can access the existing share data and create files, write and delete etc but can’t create new shares.

Screenshot at 2024-04-29 14-44-34
Screenshot at 2024-04-29 14-44-34902×618 20.3 KB

Screenshot at 2024-04-29 14-45-55
Screenshot at 2024-04-29 14-45-55928×624 40 KB

How can I get the correct permissions reset on the master share folder?
/home/samba1/.local/share/containers/storage/volumes/shares/_data

Any help would be appreciated.

As an aside I also noticed that trying to run Set Permissions causes permissions to be set on a share which stops the user being able to edit existing files, but I can create new files which can then be edited, deleted or renamed. The fix is to copy all my 367GB off the share to a local desktop, then copy back into the share which seems strange. I hope it’s not another Debian 12 bug

2

Did you change permissions from default value?

If everything was previously working and now it’s not, why do you think it’s an OS-level problem? Please provide more information about it.

3

As far as I’m aware I haven’t touched the permissions on that folder… But as I’ve encountered a couple of glitches with Debian 12 and NS8 (Nextcloud crashing with gateway time out occasionally, webtop mail not running, or linking into mail server correctly when it finally runs. Mail app having open relay when a local network IP is allowed to relay only) and I was wondering if it was a known Debian 12 issue after running updates.

But most importantly how do I reset the permissions back? Do I use a su samba user and set using chown?

Any help would be appreciated.

4

Please, check the permissions of the shares directory

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

The output of that command by my side is:

getfacl: Removing leading '/' from absolute path names
# file: srv/shares
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

You can try to change the permissions with:

runagent -m samba1 podman exec samba-dc chown -c root:root /srv/shares
runagent -m samba1 podman exec samba-dc chmod -c 755 /srv/shares
1 Like
5 
root@nelson:~# runagent -m samba1 podman exec samba-dc chown -c root:root /srv/shares
chown: changing ownership of '/srv/shares': Operation not permitted
root@nelson:~# runagent -m samba1 podman exec samba-dc getfacl /srv/shares
getfacl: Removing leading '/' from absolute path names
# file: srv/shares
# owner: nobody
# group: nogroup
user::rwx
group::r-x
other::r-x

OK Now I’m confused how can a share become nogroup and nobody for owner. No wonder I have issues. Any idea how to fix as the runagent command did not work :frowning:

6

When ownership is changed from a foreign user namespace, uid/gid numbers cannot be mapped and fall back to nobody/nogroup.

Using absolute paths like this bypasses the user namespace applied by Podman: it is a dangerous approach.

Try to revert it to a known ownership (root:root) with

chown -c samba1:samba1 /home/samba1/.local/share/containers/storage/volumes/shares/_data

Then repeat the commands I gave you previously.

Namespaces are important to understand the rich environment of containers, where service processes run: namespaces(7) - Linux manual page

7

using the below

chown -c samba1:samba1 /home/samba1/.local/share/containers/storage/volumes/shares/_data

fixed the issue. I thought it was strange that collabora1:collabora1 was the owner and group of the _data folder. Not sure how that happened but all working now.

8

Only the root user has the rights to change ownership in that way.

Do not run commands with absolute paths, expecially those that change files and dirs.

1 Like