Actions
Bug #13643
closed
smb share of lofs mount fails
Start date:
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:
Description
If one shares a path that is backed by a lofs mount using the command below (in either the gz or ngz), then a client will fail to actually mount the share.
sharemgr add-share -r some-name -s /lofs/path/ smb
This also presents a secondary issue if run from within a zone where these failed mount attempts will not decrement a reference counter of the smbuser and the zone will hang on shutdown.
> ::pgrep smb S PID PPID PGID SID UID FLAGS ADDR NAME R 15522 1 15522 15522 0 0x42320d02 fffffe23dde27128 smbd R 511 1 511 511 0 0x42000000 fffffe2392ca70a0 smbd R 499 1 497 497 0 0x42000000 fffffe2392cab140 smbiod-svc > 0t15522::pid2proc | ::walk thread | ::findstack -v stack pointer for thread fffffe23862f34c0 (smbd/1): fffffcc26c6f8a50 [ fffffcc26c6f8a50 _resume_from_idle+0x12b() ] fffffcc26c6f8a80 swtch+0x133() fffffcc26c6f8ac0 cv_wait+0x68(fffffe2832bbf1d0, fffffe2832bbf180) fffffcc26c6f8b10 taskq_wait+0xa3(fffffe2399a8f640) fffffcc26c6f8b60 taskq_destroy+0x5f(fffffe2399a8f640) fffffcc26c6f8ba0 smb_server_shutdown+0x1b0(fffffe2883a6dac0) fffffcc26c6f8bd0 smb_server_stop+0x89() fffffcc26c6f8c70 smb_drv_ioctl+0x273(d300000017, d346000a, 8047d00, 100001, fffffe287d1dede8, fffffcc26c6f8dc8) fffffcc26c6f8cb0 cdev_ioctl+0x2b(d300000017, d346000a, 8047d00, 100001, fffffe287d1dede8, fffffcc26c6f8dc8) fffffcc26c6f8d00 spec_ioctl+0x45(fffffe23a4116d00, d346000a, 8047d00, 100001, fffffe287d1dede8, fffffcc26c6f8dc8, 0) fffffcc26c6f8d90 fop_ioctl+0x5b(fffffe23a4116d00, d346000a, 8047d00, 100001, fffffe287d1dede8, fffffcc26c6f8dc8, 0) fffffcc26c6f8eb0 ioctl+0x153(21, d346000a, 8047d00) fffffcc26c6f8f10 sys_syscall32+0x138() stack pointer for thread fffffe23826ca020 (smbd/19): fffffcc269de6cf0 [ fffffcc269de6cf0 _resume_from_idle+0x12b() ] fffffcc269de6d20 swtch+0x133() fffffcc269de6d60 cv_wait+0x68(fffffe23dde271ee, fffffe23338e7380) fffffcc269de6da0 exitlwps+0x134(0) fffffcc269de6e20 psig+0x4fb() fffffcc269de6ec0 post_syscall+0x75d(4, 0) fffffcc269de6f00 syscall_exit+0x60(fffffe23826ca020, 4, 0) fffffcc269de6f10 0xfffffffffb800f9a()
> ::smblist
SERVER ZONE STATE
fffffe2393412a80 0 RUNNING
fffffe2883a6dac0 23 STOPPING
SESSION IP_ADDR PORT DIALECT STATE
fffffe2375309018 10.0.1.214 54646 0x302 DISCONNECTED
USER UID SSNID ACCOUNT
fffffe23934c9a08 1 1dc536a35d8 TIMEMACHINE\link
fffffe28cf218020 10.0.1.214 54656 0x302 DISCONNECTED
USER UID SSNID ACCOUNT
fffffe23934c98c8 1 1dc536a371f TIMEMACHINE\link
fffffe28d7902008 10.0.1.214 54708 0x302 DISCONNECTED
USER UID SSNID ACCOUNT
fffffe23934c9788 1 1dc536a385f TIMEMACHINE\link
fffffe27f1b22010 10.0.1.214 54712 0x302 DISCONNECTED
USER UID SSNID ACCOUNT
fffffe23934c9648 1 1dc536a399f TIMEMACHINE\link
fffffe23c315e018 10.0.1.214 54731 0x302 DISCONNECTED
USER UID SSNID ACCOUNT
fffffe23934c9508 1 1dc536a3adf TIMEMACHINE\link
fffffe2825f91020 10.0.1.214 54736 0x302 DISCONNECTED
USER UID SSNID ACCOUNT
fffffe23934c93c8 1 1dc536a3c1f TIMEMACHINE\link
> fffffe23934c9508::smbuser -v SMB user information (fffffe23934c9508): UID: 1 SSNID: 1dc536a3adf State: 2 (LOGGING_OFF) Flags: 0x00000000 <> Privileges: 0x00800000 <CHANGE_NOTIFY> Credential: fffffe23d823ee40 Reference Count: 2 User Account: TIMEMACHINE\link > fffffe23934c93c8::smbuser -v SMB user information (fffffe23934c93c8): UID: 1 SSNID: 1dc536a3c1f State: 2 (LOGGING_OFF) Flags: 0x00000000 <> Privileges: 0x00800000 <CHANGE_NOTIFY> Credential: fffffe27e16f0a60 Reference Count: 2 User Account: TIMEMACHINE\link
Updated by Gordon Ross about 2 years ago
- Status changed from New to In Progress
- Assignee set to Gordon Ross
Updated by Michael Zeller about 2 years ago
Just to clarify a little more on what's going on.
It seems that smb_tree_getattr returns ESTALE because of this check:
1107 if (getvfs(&vfsp->vfs_fsid) != vfsp)
1108 return (ESTALE);
root - ellie ~ # dtrace -n 'fbt::smb_tree_getattr:entry {print(args[1]->vp->v_vfsp)} fbt::getvfs:return {print(args[1])}'
dtrace: description 'fbt::smb_tree_getattr:entry ' matched 2 probes
CPU ID FUNCTION:NAME
29 83282 smb_tree_getattr:entry struct vfs * 0xfffffe23a0639438
29 34933 getvfs:return struct vfs * 0xfffffe23a1f1a5e0
21 83282 smb_tree_getattr:entry struct vfs * 0xfffffe23a0639438
21 34933 getvfs:return struct vfs * 0xfffffe23a1f1a5e0
The vfs_t's returned are different but the vfs_fsid's are the same:
> 0xfffffe23a1f1a5e0::print -t vfs_t vfs_fsid
fsid_t vfs_fsid = {
int [2] vfs_fsid.val = [ 0x2004b4d8, 0xf2b30708 ]
}
> 0xfffffe23a0639438::print -t vfs_t vfs_fsid
fsid_t vfs_fsid = {
int [2] vfs_fsid.val = [ 0x2004b4d8, 0xf2b30708 ]
}
Updated by Gordon Ross about 2 years ago
With the fix shown here: https://code.illumos.org/c/illumos-gate/+/1347/2
I was able to connect to a share of a lofs mounted dir in the zone.
Updated by Electric Monk about 2 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
git commit af536d7d6143277f3f642ce0ab6794bdd09083ed
commit af536d7d6143277f3f642ce0ab6794bdd09083ed
Author: Gordon Ross <gordon.ross@tintri.com>
Date: 2021-04-24T13:06:34.000Z
13643 smb share of lofs mount fails
Reviewed by: Alexander Stetsenko <alex.stetsenko@gmail.com>>
Reviewed by: Andy Fiddaman <andy@omniosce.org>
Reviewed by: Mike Zeller <mike.zeller@joyent.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Actions