Samba problem: Comp2 can see Comp1, but Comp1 can't see Comp2

Until recently, my 3 main computers could all “see” each other over my home network:

  1. Excalibur (dsktp. PC, Manjaro Linux)
  2. Square Rigger (dsktp. PC, Manjaro Linux)
  3. Ketch (notebook, MS Win 10)

However, about two weeks ago, Square Rigger became invisible to the other two computers, though they are visible to it.

By “Visible”, I mean that each computer could access specifically-shared directories on the other two. This was accomplished by Samba sharing (outbound) and CIFS mounting on lines in “/etc/fstab” (inbound).

But about two weeks ago, attempts to mount Square Rigger’s shared directories in Excalibur – say, “sudo mount /home/aragorn/net/SR/Lothlorien” – suddenly starting producing “mount error(13): Permission denied” errors. Whereas doing the opposite – getting on Square Rigger and doing “sudo mount /home/aragorn/net/EX/Celephais” – works fine.

So I did “sudo systemctl status smb.service” on both computers, with drastically different results:

Excalibur accepts connection from Square-Rigger:

But Square-Rigger rejects connection from Excalibur with PAM errors:

So, what could be causing this?

Please do not post screenshots of text - you know better :grin:

Clearly the user is rejected.

Could be a password change which is not synced to samba.

1 Like

I don’t see why not. Saves a lot of time, prevents typos, and preserves formatting, colors, non-text markings, etc.

Yes. But the real questions are “Why?” (something to do with that “unknown PAM error”?) and “What can be done about it?”.

That’s the first thing I thought, but no, that isn’t it. I made sure that OS user “aragorn” and Samba user “aragorn” both have the same password on both machines. And, passwords have not changed, and yet Square-Rigger stopped accepting incoming connections about 2 weeks ago. So it’s apparently not a password issue. Something else is going on, but I can’t tell what.

because images uses more server storage and bandwidth than pure text and you achieve the same result but it is searchable.

Check if you have AppArmor installed and activated.

AppArmor is know to disturb samba occasionally.

1 Like

I just went through a similar issue adding a brand new Manjaro machine to my home network. I had the “smb_pam_account: PAM: UNKNOWN PAM ERROR (9)…” errors and it was super frustrating. I used the AppArmor commands I got from one of @linux-aarhus guides.

I’d be curious to know if that fixes your situation.

It’s true that a 177kB pic uses same space as a 30k-word novella. But considering that most drives these days are over 1,000,000,000kB, the importance of that fact is somewhat diluted.

Doesn’t capture interesting non-text tidbits.

Good point. Touché. Ok, I’ll try to limit use of pics when text will work.

Lemme check… yep, installed and loaded. However, it’s also installed and loaded on my main computer, but it doesn’t have this problem. Let me check some configuration files…

Oops, I can’t check any configuration files, even as root! What the devil??? What’s up with permissions on “/etc”??? Lemme do “la -al” on “/”… Ewww… what the heck is up with this mess???

drwxr-xr-x  20 root    root     4096 2024-02-21 20:12 ./
drwxr-xr-x  20 root    root     4096 2024-02-21 20:12 ../
lrwxrwxrwx   1 root    root        7 2024-01-19 10:16 bin -> usr/bin/
drwxr-xr-x   5 root    root     4096 2024-05-05 14:43 boot/
drwxr-xr-x   4 root    root     4096 2022-04-04 13:12 .config/
drwxr-xr-x  19 root    root     4680 2024-05-07 15:56 dev/
d-wx--x--x 151 root    root    12288 2024-05-07 15:25 etc/
drwxr-xr-x   7 root    root     4096 2022-11-28 20:25 home/
lrwxrwxrwx   1 root    root        7 2024-01-19 10:16 lib -> usr/lib/
lrwxrwxrwx   1 root    root        7 2024-01-19 10:16 lib64 -> usr/lib/
d-wx------   2 root    root    16384 2022-01-27 11:44 lost+found/
d-wx--x--x   5 root    root     4096 2022-02-04 02:47 media/
d-wx--x--x   3 root    root     4096 2022-11-14 18:04 mnt/
d-wx--x--x   8 root    root     4096 2023-04-18 18:54 opt/
dr-xr-xr-x 300 root    root        0 2024-05-07 14:53 proc/
d-wx--x---  20 root    root     4096 2024-05-07 15:54 root/
drwxr-xr-x  37 root    root      940 2024-05-07 15:00 run/
lrwxrwxrwx   1 root    root        7 2024-01-19 10:16 sbin -> usr/bin/
d-wx-wx-wx   2 aragorn aragorn  4096 2022-11-05 07:15 share/
lrwxrwxrwx   1 root    root       20 2022-09-16 21:33 snap -> /var/lib/snapd/snap//
drwxr-xr-x   5 root    root     4096 2022-02-06 18:10 srv/
dr-xr-xr-x  13 root    root        0 2024-05-07 14:53 sys/
drwxrwxrwt  19 root    root      560 2024-05-07 15:36 tmp/
drwxr-xr-x  12 root    root     4096 2024-05-07 15:25 usr/
drwxr-xr-x  13 root    root     4096 2024-05-07 14:53 var/
--w-------   1 root    root    19449 2021-09-07 09:35 desktopfs-pkgs.txt
-rw-r--r--   1 root    root        8 2021-09-07 09:35 .manjaro-tools
--w-------   1 root    root     4952 2021-09-07 09:29 rootfs-pkgs.txt

Wow, lots of errors there! Even root is prohibited from reading “etc”, “lost+found”, “media”, “mnt”, “opt”, “root”, “share”. And “media” and “share” aren’t even supposed to be there!

Ok, I fixed the permissions errors (with many uses of “sudo chmod 0755 xxxxx”). I moved “media” back inside “/run” where it belongs. And “share” turned out to contain only an old 5.15 Linux kernel ISO file from 2022 so I just erased that. Let me restart system…

Ok, on restart, problem is fixed! Excalibur (my main computer) can now access shares on Square-Rigger (the computer that was having the sharing problems).

As for how the permissions got screwed-up, I have no clue. That’s not something I would do. And I don’t think the OS would do that. And most software doesn’t have permission to do that because the affected directories are owned by root. So apparently some piece of software with elevated permissions did it. Who when how where why, I have no idea; colour me puzzled. But for now it’s fixed. Hopefully this was a one-time fluke.

Also … is this accurate?
Or was it following an example from @Aragorn here?

Also some of those directories (.config, share) seem out of place.

1 Like

Nope, he has already long confessed to using my name as one of the user accounts on his computer. :wink:

1 Like

Yeah and copy-pasting text will create typos and took so much time out of your life. We don’t care about stupid colors and non-text markings.

People should just ignore lazy posts with images. Why bother if you can’t.

This is possibly the case of a mistyped command e.g. sudo chmod u-r / etc/bla/ -R

Yep. I’ve been using “aragorn” as my main user name on Linux computers since Jan 2022 (shortly before joining this forum).

Yep. “media” somehow got plucked out of “/run” and dumped into “/”. I’ll have to research where that “.config” came from; looks like it, too, got “plucked” from somewhere and dumped in “/”. The “share” just had one (old, unnecessary) file, so I just erased it. (Fortunately, “/usr/share” is intact, so that’s not where it was “plucked” from.) I dunno how those directories got “plucked”; puzzling.

Possibly. Whether that was the case here or not, one take-away is, when performing maintenance needing elevated privileges, navigate as far down the file-system tree as possible before issuing commands, to localize possible damage. Bad: navigate to “/” and do “sudo command /apple/orange/pear/tangerine”. Good: navigate to “/apple/orange/pear” and do “sudo command tangerine”.

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.