1 out of 4 SMB shares has gone RO; how?

[ChrisRM]

This is FreeNAS-11.2-RELEASE-U1, and there's a single pool, with a couple of datasets. One of those is sub-divided up into SMB shares, one of which is a general purpose household media share (music/videos/whatever). The media share has gone read-only, apparently overnight, whilst the others still have R/W, and I am at a loss how this happened or how it can be undone. I have looked though a considerable number of posts/videos/rants about this sort of question and, although I sympathize, I still find I have the problem. I can create a new share that behaves as I expect, so moving the content would seem reasonable, but I still can't get rid of the old share. Any thoughts?

thanks,

Chris M

 

[anodos]

Post content of smb4.conf

 

[ChrisRM]

Apologies for the delay in posting, some bit-rot got out of hand on another machine...

[root@Heap /etc/local]# cat smb4.conf
[global]
server min protocol = SMB2_02
server max protocol = SMB3
interfaces = 127.0.0.1 192.168.0.17
bind interfaces only = yes
encrypt passwords = yes
dns proxy = no
strict locking = no
oplocks = yes
deadtime = 15
max log size = 51200
max open files = 231032
logging = file
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
getwd cache = yes
guest account = nobody
map to guest = Bad User
obey pam restrictions = no
ntlm auth = yes
getwd cache = yes
guest account = nobody
map to guest = Bad User
obey pam restrictions = no
ntlm auth = yes
directory name cache size = 0
kernel change notify = no
panic action = /usr/local/libexec/samba/samba-bac
nsupdate command = /usr/local/bin/samba-nsupdate
server string = FreeNAS Server
ea support = yes
store dos attributes = yes
lm announce = yes
null passwords = yes
acl allow execute always = true
dos filemode = yes
multicast dns register = yes
domain logons = no
local master = no
idmap config *: backend = tdb
idmap config *: range = 90000001-100000000 server role = standalone
netbios name = HEAP
workgroup = MITCHELL
security = user
create mask = 0666
directory mask = 0777
client ntlmv2 auth = no
dos charset = CP437 unix
charset = UTF-8 log level = 1
ea support = no store dos
attributes = no map
archive = no map
hidden = no map
readonly = no

[Chris]
path = "/mnt/PileVolume/Chris"
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
map system = no
path = "/mnt/PileVolume/Chris"
printable = no veto
files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
access based share enum = no
vfs objects = zfs_space zfsacl streams_xattr
hide dot files = yes
guest ok = yes
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare

[Music]
path = "/mnt/PileVolume/Music"
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
access based share enum = no vfs
objects = zfs_space zfsacl streams_xattr
hide dot files = yes
guest ok = yes
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare

[Viv]
path = "/mnt/PileVolume/Viv"
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
access based share enum = no
vfs objects = zfs_space zfsacl streams_xattr
hide dot files = yes
guest ok = yes
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare

[media]
path = "/mnt/PileVolume/media"
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
access based share enum = no
vfs objects = zfs_space zfsacl streams_xattr
hide dot files = yes
guest ok = yes
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare

[public]
path = "/mnt/PileVolume/public"
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
access based share enum = no
vfs objects = zfs_space zfsacl streams_xattr
hide dot files = yes
guest ok = yes
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare

 

[anodos]

post output of "getfacl /mnt/PileVolume/media"

 

[l@e]

Or you can go to that dataset and check “default permisions” and reset.
Will have to set again the correct permisions via the wind machine

 

[ChrisRM]

Sorry for the delay in answering; I'd had enough of computers last night and retired to a couch with a book and some wine...

[root@Heap ~]# getfacl /mnt/PileVolume/media
# file: /mnt/PileVolume/media
# owner: root
# group: wheel
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
everyone@:r-x---a-R-c---:fd-----:allow
[root@Heap ~]#

 

[ChrisRM]

Or you can go to that dataset and check “default permisions” and reset.
Will have to set again the correct permisions via the wind machine

Fun thing about doing that is that FreeNAS requires that you confirm and continue at the field level, then 'Save' at the dataset level; this is all reasonable until one discovers that the 'Default permissions' flag has been unset, as if nothing ever happened...

 

[l@e]

I think that is not suposed to stay checked. But more as one time apply. Not sure, but it saved me when deleted the user and group from smb before setting the new one

 

[ChrisRM]

Well, the thing is that it made no difference in the behaviour of the dataset, so it's as if it was never reset.

 

[l@e]

Well, the thing is that it made no difference in the behaviour of the dataset, so it's as if it was never reset.

What user are using to connect to that share? Is that member of wheel group?

 

[ChrisRM]

What user are using to connect to that share? Is that member of wheel group?

Nope, only root is member of the wheel group. There's an alternative group (Windows) for users wishing to access these things and for the other three shares, these work just fine. This one worked just fine up until 3 or 4 days ago, then <something> changed.

 

[l@e]

Try smth. Create a user member of the wheel and use that one for conecting to that share. Then you should have the possibility to modify acl in windows machine. Use “net use * /delete” from elevated cmd to forget credentials the windows machines remembers. If you have any maped drive it will disconect. Than windows should ask for new credentials and put tgose of the new user. (For some reasons i have not investigated never worked for me with root)

 

[ChrisRM]

Nice one! That works, although I'd love to know why it went odd like that. Thanks.

 

[l@e]

Glad it did solve.
Hard to say why but if you were not using root before or any of the wheel group, based on the acl you posted i can assume you did reset permisions somehow. If it happens again just recall last commands or modifications you make. There should be some logs somewhere but if you made a lot of tries now it would be hard to get what caused.