So...
First off you shouldn't need to set a password for root (on either client or server), and even if you have unless you have created a Samba user called root on the server doing so won't help.
Next...
This is Linux to Linux so the best fix is to stop using Samba/smb/cifs and use NFS instead.
The smb protocol has no support for Linux owner, group, and permissions*. What you see is a fiction created on the client in the driver and derived from the mount options you supply**.
To further complicate that, the Samba server cannot grant permissions to clients that the underlying OS and file system doesn't grant to it. Clients do not see the actual owner, group, and permissions that are present server side. Only the Samba server does.
For a noddy example:That connects to the server as the Samba user root and prompts for a password. That's the password for the Samba user on the server not for the Linux user on either the client or the server.
Assuming the mount succeeds, all files and directories will have the following properties:
some-file-or-directory rwxr-xr-x root:root
Local users other than root will be able to read the share and enter directories but not write to it.
Because it's using the smb protocol you will be unable to change any of those and, usually, any attempt to do so will silently fail.
If the share is read only, even though client side permissions allow writing, writing will be blocked. Same applies if the share is read/write but file system permissions on the server don't allow writing.
In case it isn't obvious, there are multiple levels of user involved:
For more, and how to address these limitations, refer to the two guides I linked you to earlier.
*: Unless you use the deprecated v1 protocol with the Unix extensions enabled. Which you really, really, shouldn't.
**: Or the default values if you don't.
First off you shouldn't need to set a password for root (on either client or server), and even if you have unless you have created a Samba user called root on the server doing so won't help.
Next...
This is Linux to Linux so the best fix is to stop using Samba/smb/cifs and use NFS instead.
The smb protocol has no support for Linux owner, group, and permissions*. What you see is a fiction created on the client in the driver and derived from the mount options you supply**.
To further complicate that, the Samba server cannot grant permissions to clients that the underlying OS and file system doesn't grant to it. Clients do not see the actual owner, group, and permissions that are present server side. Only the Samba server does.
For a noddy example:
Code:
sudo mount -t cifs //my-server/my-share /mntAssuming the mount succeeds, all files and directories will have the following properties:
some-file-or-directory rwxr-xr-x root:root
Local users other than root will be able to read the share and enter directories but not write to it.
Because it's using the smb protocol you will be unable to change any of those and, usually, any attempt to do so will silently fail.
If the share is read only, even though client side permissions allow writing, writing will be blocked. Same applies if the share is read/write but file system permissions on the server don't allow writing.
In case it isn't obvious, there are multiple levels of user involved:
- The local Linux user on the client running the mount command (with sudo that'll be root) and/or the local Linux user(s) attempting access after mounting.
- The Samba user on the server. (The default being the effective username of the user performing the mount)
- The local Linux user on the server that Samba uses to perform the actual file system access (The default being the Linux user who's name matches the name of the Samba user used at mount time.)
For more, and how to address these limitations, refer to the two guides I linked you to earlier.
*: Unless you use the deprecated v1 protocol with the Unix extensions enabled. Which you really, really, shouldn't.
**: Or the default values if you don't.
Statistics: Posted by thagrol — Sat Apr 19, 2025 4:15 pm