Project

General

Profile

Actions
Copy link

Bug #963

closed

CIFS: BAD NETWORK NAME: \\<ip address>\media spewing on console

Added by Hammel over 1 year ago. Updated 11 months ago.

Status:
Closed
Priority:
Immediate
Assignee:
Hammel
Target version:
PiBox - 3.0 - Corrino
Start date:
02 May 2023
Due date:
% Done:

100%

Estimated time:
Severity:
01 - Critical

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
Actions
Copy link
 #1

Updated by Hammel about 1 year ago

  • Severity changed from 02 - High to 01 - Critical
Actions
Copy link
 #2

Updated by Hammel 11 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.

Actions
Copy link
 #3

Updated by Hammel 11 months ago

  • % Done changed from 10 to 20

Try this fix, which says to add noperm to the mount options.

This might be an issue with pistore/pisentry later, but for now it may get rid of this message.

Actions
Copy link
 #4

Updated by Hammel 11 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.

Actions
Copy link
 #5

Updated by Hammel 11 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
Actions
Copy link
 #6

Updated by Hammel 11 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 20 to 100

Fix tested on hardware and is working.

Code committed and pushed.

Closing issue.

Actions
Copy link

Also available in: Atom PDF