Bug #963
closed
CIFS: BAD NETWORK NAME: \\<ip address>\media spewing on console
100%
Description
This isn't seen unless you switch VTs to VT2. It's unclear if this is causing any problems but should be investigated.
See
Updated by Hammel 4 months ago
- Status changed from New to In Progress
- Priority changed from Urgent to Immediate
- % Done changed from 0 to 10
This doesn't cause functional problems but it fills dmesg so that other important logs are lost after short time.
This needs to be cleaned up to make it easier to review other bugs.
Updated by Hammel 4 months ago
- Description updated (diff)
The man page for mount.cifs(8) states the following for noperm.
Client does not do permission checks. This can expose files on this mount to access by other users on the local client system. It is typically only needed when the server supports the CIFS Unix Extensions but the UIDs/GIDs on the client and server system do not match closely enough to allow access by the user doing the mount. Note that this does not affect the normal ACL check on the target machine done by the server software (of the server ACL against the user name provided at mount time).
This suggests that noperm would be fine with pisentry writing to pistore file systems, but we may want slightly tighter access rules for that.
Updated by Hammel 4 months ago
That didn't work. An example command that fails:
mount -t cifs //192.168.101.53/media /media/smb/192.168.101.53 -o username=guest,guest,noperm mount: mounting //192.168.101.53/media on /media/smb/192.168.101.53 failed: No such file or directory
The destination directory (on the local machine) exists. So it must think /media is not exported from the remote host. SMB is running on that host.
The log on the remote host looks like this:
[2024/01/12 18:05:59.141440, 0] ../../source3/smbd/service.c:787(make_connection_snum) make_connection_snum: canonicalize_connect_path failed for service media, path /media/usb
On a host where this doesn't happen the path /media/usb exists. On a host where it does happen /media/usb doesn't exist. So the problem is that /media/usb would ALWAYS need to exist to avoid these errors, instead of just creating /media/usb IF a usb storage device is added.
I tested manually adding /media/usb to a remote host that didn't have it and the host trying to mount it succeeded, stopping spewing errors for that remote host.
The fix, therefore, is to update postbuild.sh to do
mkdir -p ${TARGET}/media/usb
instead of just
mkdir -p ${TARGET}/media