![]() Since my ultimate goal is to have several concurrent users all connecting to their own home directories with their own credentials, I started experimenting with this mount incantation, specifically the multiuser option: sudo mount.cifs -o "user=me,noperm,multiuser" //freenas/me ls -al mnt/testdir/ I have not yet figured out where these unwanted options are coming from. Something has injected file_mode=0755,dir_mode=0755 into the mount options, and the resulting permissions are 0x755 on all files, regardless of their actual permissions, which is obviously wrong. However, if I do not explicitly specify vers=1.0, then this happens: //freenas/me on /home/me/mnt type cifs ls -al mnt/testdir/ However, the mount is forcing SMB version 1.0, which is old and busted. And our test directory shows up with the following modes/permissions: ls -al mnt/testdir/ Once done, the following entry appears in the mtab: //freenas/me on /home/me/mnt type cifs (rw,relatime,vers=1.0,cache=strict,username=me,domain=,uid=1000,forceuid,gid=1000,forcegid,addr=X.X.X.X,soft,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1) (The above is actually normally performed by autofs, but that turns out to be not relevant.) ![]() ![]() The current mount incantation looks something like this: sudo mount.cifs -o 'vers=1.0,username=me,uid=me,gid=me,credentials=]' //freenas/me $HOME/mnt The client is a Debian Sid (unstable) system with Samba v4.7.4 components, and cifs-utils version 6.8-1. It is basically running in standalone/workgroup mode there is no AD/domain controller, and I don't want one if I can avoid it. The server is a FreeNAS system running Samba 4.7.0. here goes one more revision to my "simple" sharing guide.The problem is that I can't get files on the CIFS share to show correct permissions on the Linux client without forcing vers=1.0 in the mount options. Alas, this is far above my paygrade as a lowly server-herder.Ĭrap, now that I have written all this stuff up I don't think the problem was really related to the groups at all. I haven't had the problem since Thor's Hammer came down on permissions through the zfs aclmode property, but a part of my wonders if this (aclmode=restricted) was just a workaround to problems with the smb.conf parameter "nfs4:mode=special" or how samba handles nfsv4 acls. I'm probably contributing my own samba voodoo to the community, but I haven't had coffee yet and I woke up too early. That means this is all very unscientific. Users 1 and 2 have almost feline levels of unreliability in reproducing the results of their samba fuzzing and almost feline levels of indignation when I try to get their fuzzing methods from them (they think I'm mocking their ability to properly use a computer). The problem didn't seem to appear if the dataset was owned by a user who didn't have an identically-named primary group. Then in typical samba fashion (2+2 = 15), I ended up with random "deny" ACE being generated for the file owner with a few other random ACEs being generated for good measure. ![]() # group: evidently, samba got confused by the lack of ACE in the root directory of the share when file ownership changed through user1 generating a new file. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |