TOS 6.0.420 Beta Is Available for Testing

[TMroy]

Thank you for your feedback.
We haven't been able to reproduce this fault phenomenon yet. It is estimated to be caused by incomplete system updates, and we need to further verify it.

[tanktarta]

After being rescued from a failed upgrade from 6.0.420 to 6.0.436 by TM support, I am now experiencing very high CPU usage by the smbrichacl process. It appears to start off at 100% on one core, but at some point gets a lot worse and the whole system becomes unresponsive. If you are lucky enough to be already SSH'd into the NAS and notice this happening, it can be killed before the NAS becomes unusable. If not, the only option is a hard power off (hold down power button).

It appears that whatever support did downgraded me again to 6.0.420, but the OS is now offering an upgrade to 6.0.436 again. It would be foolish of me to try and upgrade again to 6.0.436 given how the last one went.

One thing I have found, the name smbrichacl led me to /var/log/samba/log.smbrichacl. This file is 100MB and is just filled with the endless text ...

Code: Select all

delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.Failed to delete empty record.

Can anyone tell me what exactly this process is doing and what configuration might result in this behaviour?

[Gremlin]

Just Guessing - SMB (Server Message Block) Rich ACL(Access Control List

Maybe try turning off SMB service and see.

[tanktarta]

Yeah, it is definitely samba related. It appears that *smbrichacl* is run whenever any kind of permissions are changed in the web UI. Watching the process in *top*, it looks like it has a serious memory leak and will quickly fill up *all* memory. Thats when the system starts to become unusable (understandably).

I think the failed upgrade has made a bit of a mess of permissions and users and groups. It looks like some groups and users were lost, some were not. Some got different UIDs or GIDs, some kept them. Perhaps this is why.

I'll try as you suggested and turn that off as temporary measure. I do mainly have Linux clients, and prefer to use NFS anyway (not that this is working perfectly either, buts that another story!).

[tanktarta]

Yes, turning off SMB does stop smbrichacl from being run when permissions are changed. So I think i can now at least correct the basic unix permissions without triggering this problem.

[tanktarta]

Spoke to soon. It just started itself up again!

[golgoth]

Did you notice if the high usage starts when transfering files?

[tanktarta]

Did you notice if the high usage starts when transfering files?

This appears OK for me. I haven't used in anger, but just tried a few large files and that all seems ok over NFS and SMB and it did not go over 8% CPU.

For me it always seems to happen sometime soon after going to Control Panel -> Shared Folders -> Edit -> Permissions and then just applying a change.

[tanktarta]

SOLVED

Ahah!

Well, I my found problem. This issue stemmed from the failed upgrade (and I assume the recovery had a part to play). Somehow the user superuser had ended up with a UID of *11* at one point where of course it should be zero. At some point, this UID had also been written to /etc/samba/smbp.
This file appears to map windows IDs to unix IDs

Code: Select all

guest:1001:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:AAAAAAAAAAAAAAAAAAAAAAAAAAAAA:[U          ]:LCT-111111111:
superuser:11:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:BBBBBBBBBBBBBBBBBBBBBBBBBBBBB:[U          ]:LCT-22222222:
xxxxxxxx:12:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:CCCCCCCCCCCCCCCCCCCCCCCCCC:[U          ]:LCT-33333333:
... more

By correcting these IDs, smbrichacl would then complete without going into a fatally memory consuming loop.

I found this by capturing the arguments that were used to run this command, and running it myself. Happily the command has some debug logging options, and I noticed this block of text repeating over and over again.

Code: Select all

Trying _Get_Pwnam(), username as lowercase is superuser
Get_Pwnam_internals did find user [superuser]!
Forcing Primary Group to 'Domain Users' for superuser
lookup_global_sam_rid: looking up RID 1000.
getsmbfilepwent: returning passwd entry for user guest, uid 1001
getsmbfilepwent: returning passwd entry for user superuser, uid 11
getsmbfilepwent: returning passwd entry for user xxxxxxxxx, uid 12
//// MORE OF THESE
getsmbfilepwent: end of file reached

So in short, smbrichacl has (or had) a fatal bug that triggers if the UIDs in /etc/samba/smbp are incorrect.

Question For TM Why do "real" users (and groups_, i.e. those I create in the user interface, have low UIDs that get mixed in with system created users. This is a bit unusual. I would expect high numbers, like above 1000 or 10000. It would also be incredibly useful it it were possible to configure the UID and GID of users and groups respectively in the user interface, and of course have it correctly update smbp!

[Gremlin]

Ahah!

Should we call you Alan?