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

[robbie-hatley]

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?

[linux-aarhus]

Please do not post screenshots of text - you know better

Clearly the user is rejected.

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

[robbie-hatley]

@linux-aarhus

Please do not post screenshots of text

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

@linux-aarhus

Clearly the user is rejected.

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

@linux-aarhus

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

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.

[linux-aarhus]

@robbie-hatley

I don’t see why not

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

@robbie-hatley

Something else is going on, but I can’t tell what.

Check if you have AppArmor installed and activated.

AppArmor is know to disturb samba occasionally.

[rob215x]

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.

[robbie-hatley]

@linux-aarhus

images uses more server storage

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.

@linux-aarhus

achieve the same result

Doesn’t capture interesting non-text tidbits.

@linux-aarhus

searchable

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

@linux-aarhus

AppArmor installed and activated

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.

[cscs]

@robbie-hatley

d-wx-wx-wx 2 aragorn aragorn 4096 2022-11-05 07:15 share/

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

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

[Aragorn]

@cscs

@robbie-hatley

d-wx-wx-wx 2 aragorn aragorn 4096 2022-11-05 07:15 share/

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

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

[anon51566685]

@robbie-hatley

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

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.

[linux-aarhus]

@robbie-hatley

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???

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

[robbie-hatley]

@cscs

Also … is this [user name “aragorn”] accurate?

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

@cscs

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

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.

@linux-aarhus

mistyped command e.g. sudo chmod u-r / etc/bla/ -R

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”.