2

There are three machines in a network for this minimal example. A windows server acts as a domain (with everything that involves), a Synology NAS that's used to store some data and backups, and a Linux host that needs to access that same NAS.

Since I don't want to mess up or maintain a separate set of permissions on the NAS, the Linux host should just use the same access mechanism that the windows hosts do; for that, I mount the share as CIFS and ask a Kerberos ticket from the windows server. This functions; and the share mounts.

But then I encounter something that can only really be described as a WTF?.

Suppose the domain has two users, wuB and wuV. The user wuV has created a folder on the Synology share. I now want to access this file as the (windows domain) user wuB, from the Linux host.

I run the following on a Linux machine:

$ kinit [email protected] $ mount --verbose -t cifs -o sec=krb5i,vers=2.0,username=root,uid=0000,gid=0000,iocharset=utf8,dir_mode=0777,file_mode=0777,noperm //mysynology.company.com/backup /var/backups/synology1 mount.cifs kernel mount options (...) $ cd /var/backups/synology1/ $ ls existing_dir_owned_by_wuV $ mkdir testdir $ cd testdir $ touch testfile $ echo "yessir" > testfile $ cat testfile yessir $ ls -lha drwxrwxrwx 2 root root 0 Sep 20 12:28 . drwxrwxrwx 2 root root 0 Sep 20 12:28 .. -rwxrwxrwx 1 root root 6 Sep 20 12:28 testfile $ cd .. $ cd existing_dir_owned_by_wuV $ ls -la '.' : permission denied $ cat existing_file_in_subfolder permission denied $ cd .. $ cat existing_file_in_mainfolder hello world

Checking the ownership on the synology: it's marked as owned by company.com/wuB for the testfolder, the existing folder is marked as owned by company.com/wuV. This means that yes, I am accessing the share as the windows user wuB here.

On the synology the Windows/NTFS style permissions are set only on the share itself; subfolders/files inherit permissions only. Both wuV and wuB are marked as having Read&Write access on all the files in the share. When mounting, the linux permissions are set to 777. I'm doing all the operations as root on the linux machine so the permissions issues aren't originating from there either.

How is this even possible?

How do I solve the problem?

Improve this question

1 Answer 1

Reset to default
0

For those with a similar problem; I found the answer:

Synology's display of NTFS permission is, essentially, wrong. It caches them somehow, and displays it's own version of reality, which doesn't exactly match up with how SMB/CIFS is storing things. I found this out by mounting the folder from a windows machine as the same user. I could not access some of the existing directories.

It turns out that the tracking of inheritance is buggy. NTFS permissions are complicated, each folder has its own inherit flag. If any of these are set off, then permissions on the share won't apply. It turns out a buggy program was making some of the folders/files it writes without respecting the administrator's inheritance settings. (but not the administrator's ability to change these permissions anyway). Why this is even possible is one of those Windows committee design warts.

The solution is to turn on inheritance (and do so for all files and subfolders) on each of the problematic folders. Can be automated with cacls, or done in that same explorer window.

While reviewing this answer I also came accross ntfssecaudit, a way to do the same thing from the linux host if there's no windows machine available. It too reports inheritance as being off if the user connecting has the rights to view these things; but this is simply solved by re-mounting using a kerberos ticket for administrator.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.