251009-windows共享Win10-11设置无密码访问共享文件夹

无密码共享

启用Guest账号(计算管理启用Guest账号)

配置安全策略(可选)

  • WINDOWS键+R然后“运行”里输入“secpol.msc”，点击“确定”打开本地安全策略。
  • 找到“本地策略” > “安全选项” > “网络访问：本地账户的共享和安全模型”，改为“仅来宾-对本地用户进行身份验证，其身份为来宾”后确定。
  • 找到“本地策略” > “安全选项” > “账户：来宾账户状态”，点击“已启用“后确定。
  • **(重要)**找到“本地策略” > “用户权限分配” > “拒绝从网络访问这台计算机”，选择“Guest”账户后，点击“删除”，最后确定即可。

【WindowsServer】你不能访问此共享文件夹

因为你组织的安全策略阻止未经身份验证的来宾访问。这些策略可帮助保护你的电脑免受网络上不安全设备或恶意设备的威胁。

解决办法

要调整组织的安全策略以解决“阻止未经身份验证的来宾访问”的问题，你可以尝试以下方法：

  1. 修改组策略：

    • 按 Windows + R 键打开运行窗口，输入 gpedit.msc 并回车，启动本地组策略编辑器。

    • 导航至“计算机配置” > “管理模板” > “网络” > “Lanman 工作站”。

    • 找到“启用不安全的来宾登录”选项，双击并将其状态修改为“已启用”，然后点击“确定”按钮保存设置

  2. 修改注册表：

    • 按 Windows + R 键，输入 regedit 打开注册表编辑器。

    • 找到路径 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters。

    • 如果不存在名为“AllowInsecureGuestAuth”的DWORD值，则需要新建一个，将其值设置为1，这个注册表项的作用是允许不安全的来宾身份验证

请注意，启用不安全的来宾登录可能会降低系统的安全性，因此在启用此设置之前，请确保你了解相关的安全风险，并根据实际情况做出决策。
同时，修改注册表有一定风险，如果操作不当可能会导致系统不稳定，所以在修改之前最好备份注册表或者创建系统还原点。

Win10-11设置无密码访问共享文件夹

1、建立要享文件夹soft

2、选中并右键该文件夹-属性-共享-高级共享

3、点击-权限，加入everyone并添加其权限

4、关闭密码保护共享

回到要共享的文件夹属性-密码保护-网络和共享中心

高级共享设置—所有网络-密码保护的共享-关

5、配置安全策略(可选)

WINDOWS键+R然后“运行”里输入“secpol.msc”，点击“确定”打开本地安全策略。
找到“本地策略”-“安全选项”-“网络访问：本地账户的共享和安全模型”，改为“仅来宾-对本地用户进行身份验证，其身份为来宾”后确定。
找到“本地策略”-“安全选项”-“账户：来宾账户状态”，点击“已启用“后确定。
找到“本地策略”-“用户权限分配”-“拒绝从网络访问这台计算机”，选择“Guest”账户后，点击“删除”，最后确定即可。

250929-Java-Semaphore信号量多线程并发控制

多线程并发信号量控制逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
/**/
private static final ConcurrentHashMap<String, Long> LOCK_DTO_MAP = new ConcurrentHashMap<>();

private static final ConcurrentHashMap<String, Semaphore> SEMAPHORE_MAP =
    new ConcurrentHashMap<>();

private static final long TIMEOUT_DURATION = 60_000; // 60 seconds

public static boolean lock(String key) {
  Semaphore semaphore = SEMAPHORE_MAP.computeIfAbsent(key, k -> new Semaphore(1, true));
  boolean acquired = false;

  try {
    // 1. 拿到许可证
    acquired = semaphore.tryAcquire(1, TimeUnit.SECONDS);
    Preconditions.checkState(acquired, "获取锁超时: " + key);

    // 2. 现在互斥了，再操作被保护资源
    Long old = LOCK_DTO_MAP.putIfAbsent(key, System.currentTimeMillis());
    Preconditions.checkState(old == null, "Lock already held by this thread for key: " + key);

    return true;
  } catch (Exception ignored) {
  } finally {
    /* 4. 关键：只有真正拿到过许可的线程才需要“善后” */
    if (acquired) {
      /* 4.1 判断是否超时，超时就当“没发生过”直接删记录 */
      try {
        long holdTime = System.currentTimeMillis() - LOCK_DTO_MAP.get(key);
        if (holdTime > TIMEOUT_DURATION) {
          LOCK_DTO_MAP.remove(key); // 删记录" 超时，记录+许可证已清理"
        }
      } finally {
        semaphore.release(); // 还许可证
      }
    }
  }
  return false;
}

/** 清空StripedLockUtils的所有数据 */
public static void clearAppRestart() {
  for (String key : LOCK_DTO_MAP.keySet()) {
    StreamUtils.silentException(
        () -> {
          unlock(key);
          SEMAPHORE_MAP.remove(key);
        });
  }
}

public static void unlock(String key) {
  StreamUtils.silentException(() -> LOCK_DTO_MAP.remove(key));
}

250927-RPM查看安装软件和卸载软件(rpm -qa | grep mongodb-org)

  1. 确认已安装的 MongoDB 家族版本

    1
    rpm -qa | grep mongodb-org

典型输出：

1
2
3
4
5
mongodb-org-server-8.2.0-1.el8.x86_64
mongodb-org-shell-8.2.0-1.el8.x86_64
mongodb-org-tools-8.2.0-1.el8.x86_64
mongodb-org-mongos-8.2.0-1.el8.x86_64
mongodb-org-database-tools-extra-8.2.0-1.el8.x86_64

  1. 卸载

    1
    rpm -e mongodb-org-server-8.2.0-1.el8.x86_64

输出

1
2
Removed /etc/systemd/system/multi-user.target.wants/mongod.service.
warning: file /run/mongodb: remove failed: No such file or directory

250913-Shell工具Shell-MobaXterm重置主密码工具

mobaxterm密码忘记，如何重置密码？

解决方法： 使用MobaXterm主密码重置工具ResetMasterPassword，一键去除打开软件主密码。

官网 MobaXterm free Xserver and tabbed SSH client for Windows (mobatek.net)

https://mobaxterm.mobatek.net/

软件去掉密码 MobaXterm Xserver and tabbed SSH client - resetmasterpassword (mobatek.net)

ResetMasterPassword.zip

https://mobaxterm.mobatek.net/resetmasterpassword.html

250902-ubuntu20.04分辨率-只有一个800x600的分辨率怎么升级

在Ubuntu 20.04中，如果遇到分辨率只有800x600的情况，可以尝试以下方法来升级或调整分辨率：

更新软件

1
2
sudo apt update
sudo apt upgrade

配置GRUB

可以在/etc/default/grub文件中找到注释掉的GRUB_GFXMODE行，取消注释并设置为你的目标分辨率，例如GRUB_GFXMODE=1920x1080
，然后更新GRUB配置并重启

1
GRUB_GFXMODE=1920x1080

250901-MySQLImport导入数据-以确保字符集的一致性--default-character-set=utf8

–default-character-set=utf8

遇到 “ERROR at line 13404: Unknown command ‘’’” 错误时，这通常是由于字符集问题导致的。为了解决在 MySQL
导入数据时的问题，可以尝试以下几种方法：

  1. 指定字符集：在导入命令中添加 --default-character-set=utf8 参数，以确保字符集的一致性。例如：

    1
    mysql -u root -h 127.0.0.1 -P 33067 --default-character-set=utf8 mujitokyo_dev<mujitokyo_dev.sql

这样可以避免因字符集不匹配导致的数据导入失败

。

  1. 检查文件编码：确保 SQL 文件的编码格式与 MySQL 服务器的编码格式一致。可以使用文本编辑器或命令行工具（如 ）来转换文件编码。

  2. 使用特定编码导出：在导出数据库时，就使用特定编码的形式导出。例如，如果需要导入的数据库环境编码是utf8，那么在导出时就使用utf8格式。

  3. 调整命令行客户端编码：在命令行客户端连接服务器时指定编码，例如：

    1
    mysql -uroot -h192.168.0.1001 -p --default-character-set=utf8

这可以避免前面遇到的错误

。

  1. 修改 max_allowed_packet 设置：如果导入的 SQL 文件较大，可能需要调整 MySQL 的 max_allowed_packet 设置，以允许更大的数据包传输

250901-MySQL--skip-grant-tables跳过权限表-处理数据库异常恢复数据

你可以将 --skip-grant-tables 选项添加到 MySQL 的配置文件中，以便在每次启动时自动应用此设置。然而，需要注意的是，
--skip-grant-tables 选项会跳过权限表的加载，这意味着所有用户都可以无需密码登录到 MySQL
服务器，这会带来重大的安全风险。因此，通常只在进行特定维护任务时临时使用此选项。

将 --skip-grant-tables 添加到配置文件

  1. 找到 MySQL 配置文件： MySQL 的配置文件通常名为 my.cnf 或 my.ini，位于 /etc/mysql/、/etc/mysql/mysql.conf.d/
    或 MySQL 安装目录下。

  2. 编辑配置文件： 打开配置文件，找到 [mysqld] 部分，并添加 --skip-grant-tables 选项。例如：

    1
    2
    [mysqld]
    skip-grant-tables

  3. 保存并关闭文件。

  4. 重启 MySQL 服务： 重启 MySQL 服务以应用更改：

    1
    sudo systemctl restart mysql

使用 --skip-grant-tables 的注意事项

  • 安全性：由于 --skip-grant-tables 会跳过权限检查，任何用户都可以无需密码登录到 MySQL
    服务器。因此，在使用此选项时，必须确保数据库服务器不对外部网络开放，或者在防火墙中严格限制访问权限。
  • 临时使用：通常只在需要修复权限表或进行其他需要跳过权限检查的维护任务时临时使用 --skip-grant-tables
    。完成这些任务后，应立即从配置文件中移除此选项，并重启 MySQL 服务。
  • 备份：在修改配置文件或进行任何可能影响数据库安全性的操作之前，确保备份所有重要数据。

从配置文件中移除 --skip-grant-tables

完成维护任务后，应立即从配置文件中移除 --skip-grant-tables 选项，并重启 MySQL 服务以恢复正常的权限检查：

250901-MySQL-LogFile-ib_logfile启动异常处理

异常信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2025-09-01T01:38:07.723468Z 0 [ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint 1108276937 and the end 1108281882.
2025-09-01T01:38:07.723499Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2025-09-01T01:38:08.332206Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2025-09-01T01:38:08.332263Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2025-09-01T01:38:08.332280Z 0 [ERROR] Failed to initialize builtin plugins.
2025-09-01T01:38:08.332294Z 0 [ERROR] Aborting

2025-09-01T01:38:08.332312Z 0 [Note] Binlog end
2025-09-01T01:38:08.332392Z 0 [Note] Shutting down plugin 'CSV'
2025-09-01T01:38:08.334119Z 0 [Note] mysqld: Shutdown complete


2025-09-01T03:20:31.722426Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-09-01T03:20:31.722543Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=635] log sequence number 1041821149 is in the future! Current system log sequence number 1040642590.
2025-09-01T03:20:31.722583Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-09-01T03:20:31.722683Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=1371] log sequence number 1040709155 is in the future! Current system log sequence number 1040642590.

从你提供的日志来看，
MySQL 在启动时遇到了与 InnoDB 存储引擎相关的问题，导致无法正常启动。
以下是日志中显示的几个关键问题及其可能的原因：

1. InnoDB 忽略重做日志

1
2
3
2025-09-01T01:38:07.723468Z 0 [ERROR] 
              InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT 
              between the checkpoint 1108276937 and the end 1108281882.
  • 问题描述：InnoDB 在启动时检查重做日志（redo log），发现缺少 MLOG_CHECKPOINT，导致无法正确恢复数据。
  • 可能原因：
    • 数据库在上次关闭时没有正常关闭，导致重做日志不完整。
    • 数据文件（如 ibdata1 或 ib_logfile*）可能被损坏或丢失。

2. 可以尝试删除的文件

**ib_logfile\***：这些是 InnoDB 的重做日志文件，用于恢复操作

在某些情况下，可以尝试删除一些临时文件或日志文件，但需要谨慎操作：

  • **ib_logfile\***：如果这些文件损坏，可以尝试删除它们，然后重新启动 MySQL。MySQL 会自动重新创建这些文件。但请注意，这可能会导致一些未提交的事务丢失。
  • **\*.err**：这是 MySQL 的错误日志文件，删除它不会影响数据库的运行，但建议先备份，以便后续查看错误信息。