Hi, i have a rather weird and also problematic use case. My NAS provides permissions but I don't know how. The share is mounted using unix extensions and I am seeing user IDs. However my /local/ filesystem refuses me to allow to do anything unless I am root or set the noperms flag (ostensibly). This means that locally write access is denied but not remotely. The local user is UID 1000. The logged in user is 1000002. The file *always* shows as rwxr-xr-x. Whether the file is remotely owned by 1000, 1026 or 1000002 doesn't make a difference. So: locally I am the owner if remotely it is owned by 1000. Locally I am in a group that remotely has write access. The file (directory) still shows as r-w for group no matter what I do (thus far) and maybe I just don't know how it works. It is made more difficult because Synology does its own permissions game so I can try to with different mount options but yeah. Apparently group write access for my logged in user (that should have it) is apparently not communicated but even if it were I doubt my system would allow writing. Maybe I should force the mode but I don't know if that is possible. I already have rwx mode for a file that should get recognised as having me as the owner (both locally as remotely but obviously not at the same time). So Linux permissions is biting me again, a Windows user would never have this problem. How on earth can I not get write access locally if even the display from ls shows me as having access? The file clearly shows as 755 AND it is owned by me. I have now tried with nomapposix and noacl as well. The moment I say "noperm" it works. The Syno thing actually works flawlessly on that local system. I really don't know, maybe I should just patch the thing to introduce a new option "nogperm" that assumes writing is okay if the group matches a group of the local user. I think this thing is broken anyway. With all the complexity of the samba product itself, it seems the kernel module is often the thing that is most shabby. Does anyone have any ideas here?
So yesterday I ran into the issue (again) that my local system (Linux)
would create local restrictions for editing and creating files that were
not mirrored on the samba server.
As a consequence I have introduced the option "nogperm" into my own
kernel that does something similar to what "noperm" does but it works
differently. While noperm skips permission checks entirely, nogperm only
skips them if the local user is part of the group of the file/directory.
Actually, that is pretty much the same thing.
Apart from the boiler plate code, this is the entirety of the patch:
diff -ur cifs_original/cifsfs.c cifs/cifsfs.c
--- cifs_original/cifsfs.c 2016-09-06 17:42:01.000000000 +0200
+++ cifs/cifsfs.c 2016-10-06 03:28:43.450711676 +0200
@@ -230,6 +230,9 @@
return -EACCES;
else
return 0;
+ } else if ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NO_GPERM) &&
+ in_group_p(inode->i_gid)) {
+ return 0;
} else /* file mode might have been restricted at mount time
on the client (above and beyond ACL on servers) for
servers which do not support setting and viewing mode bits,
Consequently, when I now mount using this option, I can now write to
this directory of which my user is in the remote group :).
At the same time, I do not provide access to the entire system. A group
check needs to happen first, and there is no free "world" access in
that
sense. Basically, it is "noperm" /IF/ you are part of the remote
group.
I am not doing any mapping here, so this is a remote LDAP group
(currently) that I am locally also part of.
Without this parameter I would see the following:
[~]:/nas/pub$ touch b
touch: cannot touch 'b': Permission denied
With the parameter, I now get:
[~]:/nas/pub$ touch a
[~]:/nas/pub$
Success! I must admit I cheered here a little bit ;-).