Created user/group doesn't own files

[LearnLearnLearn]

Running 12.0-u7.
I created a built-in user and group so that machines can log in using authentication and have access to the same files.
On the SMB shares, I made the user/group the owner with full control.

When looking at the files from a Manjaro terminal, I see everything is owned by root:root.
I would like the files owned by the user/group that I created and the mapped user that mounts the shares on Windows and Linux desktops.

I've read countless posts but feel like if I don't ask, I'm just going to break the system at this point.
I'm not sure what other info to provide but will happily do so if/when asked.

 

[anodos]

When looking at the files from a Manjaro terminal, I see everything is owned by root:root.
I would like the files owned by the user/group that I created and the mapped user that mounts the shares on Windows and Linux desktops.

When viewed from local FS on the TrueNAS server (e.g. "ls -l" in SSH session), are they owned by the expected user?

 

[LearnLearnLearn]

Hi,

When looking from ssh, they are owned by the correct user/group.
However, I've since found that it's only the Manjaro user that cannot run rsync.
That rsync is run as root but still gets Permission denied when trying to use --delete

The user is logged into the desktop which is not the same user/group as the share.

As the user;
% touch shared/testfile.txt
touch: cannot touch 'shared/testfile.txt': Permission denied

% su
# touch shared/testfile.txt
# ls -la shared/
-rwxr-xr-x 1 root root 0 Oct 7 13:56 testfile.txt

User has no access while root does but the file is written as root.
I've never had a situation like this where one user is logged in and cannot mount the share while root can but then the user has no access and even root cannot delete.

As user;
% mount -t cifs -o username=test //tn01/shared/ /home/test/shared/
mount.cifs: permission denied: no match for /home/test/shared found in /etc/fstab

The 'shared/' dir is owned by the user.
I don't have this in fstab as it's not meant to be constantly mounted.

Is the problem that user doesn't have access to mount maybe?

 

[LearnLearnLearn]

Still stumped with this. Been all up and down many rabbit holes and nothing seems to work.

smbclient -U test //tn01/shared/
Can't load /etc/samba/smb.conf - run testparm to debug it
Password for [WORKGROUP\test]:
session setup failed: NT_STATUS_LOGON_FAILURE

In journalctl I see;
IFS VFS Send error in SessSetup = -13

But nothing I've read seems to apply.

mount -t cifs -o username=test //tn01/shared/ /home/test/shared
mount.cifs: permission denied: no match for /home/test/shared found in /etc/fstab

 

[anodos]

Still stumped with this. Been all up and down many rabbit holes and nothing seems to work.

smbclient -U test //tn01/shared/
Can't load /etc/samba/smb.conf - run testparm to debug it
Password for [WORKGROUP\test]:
session setup failed: NT_STATUS_LOGON_FAILURE

This means that your Linux client probably does not have an smb.conf file. You need at a minimum for that file to exist and contain the heading

Code:

[global]

When looking from ssh, they are owned by the correct user/group.

It's important to understand that the user that you're authenticated as locally on the client, is not always the same as the user whose credentials are being used to authenticate to the remote server.

For example:
as root (on client) mount remote SMB server using credentials of "bob" (remote server).

Local FS operations while root on the local server, will be as root (owned by uid 0), but this will not in any way impact operations on the remote server (which will be done as user "bob" there). This means that if you're using `rsync` as root on the client, it will _not_ have root permissions on the TrueNAS server (will do everything as "bob").

Typically, an SMB client (whether via libsmbclient or the kernel cifs client in Linux) will retrieve information about owner and permissions in one of two ways: (1) requesting an NT security descriptor and converting it to an approximation of local FS permissions or (2) using SMB1 posix extensions to directly ask the owner / group / mode of file.

The above behavior is configurable, but in general I think the most consistent results for TrueNAS are achieved by using the `noperm` option.

 

[LearnLearnLearn]

My old server was TrueNAS-12.0-U6 and the new server is TrueNAS-12.0-U7.
I understand what you're saying about the users but I basically just copied all the settings from the old system to the new one that was going to replace it but now have these problems.

Oddly, I restored the config of truenas and now it works again.
I was sure I messed something up on the tn server by trying to figure this out and I guess this proves it.

At least I'm back to a working state so now I can get back to how to back things up.
Now that the share is working again, thanks to your suggesting I look at the files from the TN perspective, I see they are owned by the user that is authenticated at mount time.

This isn't what I'd like but it's ok as a backup at least. What I'd really like is the user to be the same as the user that owns the files on the linux box.
Right now, even as root, I can't delete files that were backed up.
When I try to remove a backed up directory, I get 'Cannot remove directory xxx. Permission denied (13)'.
When trying to copy files, I also get 'Cannot create tarket symlink "xxx". File exists (17).

In fact, I have no way what so ever of removing files unless I do it directly from the TN ssh shell.
So in the end, I don't have a way to actually sync files as needed.

 

[LearnLearnLearn]

I restored the configuration after posting the above and all is working again.
Thank you for your help.