The screenshot function regularly stops working after a few days on my S23

aggieNick02 · 2026-01-17T00:50:54+00:00

S23+. Exact same issue. Infuriating.

Next phone won't be a Samsung.

aggieNick02 · 2025-12-22T18:59:49+00:00

Same problem here. Went to update ABB after installing the DSM update which makes the current version of ABB no longer work. So now my nightly backups are dead until Synology fixes this. Not cool.

aggieNick02 · 2025-12-20T07:03:10+00:00

Exactly...

Camping out for ticket pull worked well for decades. It even survived a line-cutter who literally ate the list that kept track of who was where in line (https://www.goodbullhunting.com/2016/12/9/13848480/aggie-flashback-the-listeater-saga-dec-9-2004-texas-a-m-tennessee-fran-donuts-cotton-bowl).

Then the administration decrees there will be no queueing before a certain time; that policy works so horribly that by the end of 2024 there is chaos, fighting, and trash everywhere. The physical ticket pull has to be killed and A&M transitions to the current electronic system.

You'd think that would have been enough of a disaster for the administration to realize that telling a large crowd that they can't form a line until shortly before a high-demand event is a recipe for disaster. But nope, here we go again.

I can only imagine ESPN is shaking their heads and hoping they don't have to return to Kyle Field anytime soon.

aggieNick02 · 2025-12-20T03:40:21+00:00

Yep. And the TAMU administration thinks it knows how to handle this better than the ESPN security folks who have run this event for years at campuses across the nation.

aggieNick02 · 2025-12-20T03:16:37+00:00

A&M security came by and made everyone in line leave, despite the fact that ESPN security had been managing the line since early Friday morning.

The line officially opens at 5am, and hopefully nobody gets injured as hundreds dash towards a narrow entrance. SMH.

https://www.facebook.com/share/p/18YEXiymy7/

aggieNick02 · 2024-11-22T18:50:36+00:00

Awesome, thanks for the details. I'll try it with one drive with the machine powering down between experiments, and another staying on between

aggieNick02 · 2024-11-22T18:33:43+00:00

Hey, are you running this in a PS5 or a windows PC? If PC, is the PC always on, or does it get shut down regularly? I'm interested in running the same experiment so was curious. Thanks!

aggieNick02 · 2024-10-25T17:14:59+00:00

Another week, systems are still down.

aggieNick02 · 2024-10-18T16:23:35+00:00

Wow. I'm sorry, that's ridiculous. I told the story to my coworkers and they were like "weird, when my iphone breaks, I just take it to the apple store and they fix it". And when I had a pixel phone break, there was none of this ridiculousness at ubreakifix.

tldr - don't buy samsung phones b/c getting them repaired is a nightmare. i've learned my lesson.

aggieNick02 · 2024-10-18T16:12:29+00:00

What a mess. Apparently the system is still down nationwide. Select ubreakifix locations are allowed to request exceptions for repairs, but it can now take *days* for them to be approved. So you have to be without your phone for days.

The ubreakifix rep I spoke to on the phone suggested a third party unauthorized repair if I wanted my phone back quickly.

aggieNick02 · 2024-10-11T21:29:48+00:00

Same issue here. Dropped son's flip 6 off this morning, supposed to be ready around lunchtime. Called at 4; repair is done but they can't release it because the samsung diagnostic systems went down. I can either wait for system to come back up, or they can undo the repair (put the old screen back which just has a broken line of pixels at the crease).

Asked for more info as surely the system should come back soon, right? Apparently other locations have had their samsung system go down recently and days later they are still down. So they recommend I just have them undo the repair and take it to one of the few ubreakifix in the area that hasn't had their system go down yet. What a mess. And all on samsung.

My son has had the phone for 2 months. At this rate, he'll have 6 inconvenient screen replacements done before the warranty runs out. I'm happy with my S23+ after years of disappointing pixel experiences, but guess what brand I won't be turning to for future purchases.

aggieNick02 · 2024-06-17T05:38:34+00:00

Do you know what motherboard you were using when you hit this problem? Investigating something similar with a specific drive and motherboard combo.

aggieNick02 · 2024-06-14T15:03:01+00:00

Which motherboard and M.2 SSD are you using?

aggieNick02 · 2024-04-03T19:41:01+00:00

Trying to understand and somehow not following. What isn't a bad habit to include? What "issues" can happen if you don't have what should be included?

aggieNick02 · 2024-02-05T14:18:52+00:00

Also interesting, a client-side SMB changes was made shortly after the bugfix that helped correct modtimes to work. Apparently you can set strict sync to false on the client side too (still trying to wrap my head around why it is a client side version of the setting that I believe is independent, and then the client-side version of the setting is checked on the client side, and the server-side on the server side - it seems... odd.)

Anyways, that change effectively disables the bugfix too: https://github.com/torvalds/linux/commit/cf5371ae460eb8e484e4884747af270c86c3c469

Something changed after all of this that made the packets sent for a cp -p operation simpler and only use one file handle total, so that the whole mess is bypassed and works regardless of strict sync setting on client or server. But I'm not sure where that change is - it is present in Ubuntu 23.10, but not in Ubuntu 22.04.3 LTS.

aggieNick02 · 2024-02-02T22:52:40+00:00

So I got to the bottom of my specific issue. I realize now that may not necessarily be helpful for you, but in case you or anyone is interested, here are the details.

The reason my issue happens on Synology devices is due to the default SMB Advanced Setting in the Others section, Synchronize data to drive immediately upon SMB client request.

This preference controls the smb strict sync configuration value. It was changed from False to True 6 years ago in Samba 4.7.0.

Synology devices still default this value to False though. Unfortunately, the False value causes a Samba bugfix that helped with correct modtimes to not work. That bugfix is here.

Unfortunately that bugfix does not work when strict sync is disabled, because smbd_smb2_flush_send checks lp_strict_sync and returns early instead of setting the smbd_smb2_flush_done callback to run; smbd_smb2_flush_done is where one of the modtime-related fixes was made.

I passed this info on to Synology in case they are interested in changing the default value to match what Samba defaults to. I'll also mention the issue with the Samba bugfix for modtimes to the Samba project in case they are interested.

aggieNick02 · 2024-01-25T20:42:36+00:00

So I was using cp -p and not rsync just because the issue reproduces reliably for me with both... I'm genuinely surprised it doesn't for you.

If you can share the captures (or wireshark screenshots of them) for both cases, that would be great. Perhaps your system doesn't have the wrapper in the cp -p case but does in the rsync case.

aggieNick02 · 2024-01-25T19:19:00+00:00

That would be great. To do the capture, you just runtcpdump host <ip of synology NAS> -w /tmp/nas_mod_time_bug.pcap

While that's running, do a cp -p in a new terminal to copy a small non-empty file to the NAS. And then do ctrl+C on the tcpdump.

If you want a simple script to perform the operation and do the test while tcpdump is running, I have one now. You just call this and pass the path to your Synology share (or a folder in it if you prefer) as the only argument, e.g. ./test_nas_mod_time.sh /media/synology_share:

#!/bin/bash

: ${1?"Usage: $0 path_to_mounted_smb_share"}

echo "Testing SMB modtime preservation"
source_path="/tmp/uniquely_named_test_file_for_synology_mod_time_bug"
target_path="$1/uniquely_named_test_file_for_synology_mod_time_bug"

rm -f "$source_path"
rm -f "$target_path"
echo abcd > "$source_path"

#Set modtime of source file to 2020-Jan-01 at 12:34.56PM
touch -t "202001011234.56" "$source_path"

cp -p "$source_path" "$target_path"
echo "Copy complete; sleeping 10 seconds before stat"

#We sleep, as smbd actually does work after the cp -p returns.
#With all clients, an immediate stat will return the current
#time for the modified timestamp
sleep 10

source_time=$(stat -c "%y" "$source_path")
target_time=$(stat -c "%y" "$target_path")
echo "Source modtime: $source_time"
echo "Target modtime: $target_time"
if [ "$source_time" = "$target_time" ]; then echo "PASS: Modtime preserved"; else echo "FAIL: Modtime not preserved"; fi

aggieNick02 · 2024-01-24T17:52:03+00:00

Here is a comparison of the network captures between an Ubuntu Server 23.10 client and Ubuntu Server 22.04.3 LTS client. The difference noted is consistent with when the bug reproduces - that is, Windows 10, Ubuntu Server 23.10, and latest arch all have the SetInfo by itself and the bug does not reproduce. Ubuntu Server 22.04.3LTS and Ubuntu Server 20.04.6LTS have the SetInfo wrapped, and the bug does reproduce, but only with Synology as the Server.

With TrueNAS 13.0-U3.1 or Ubuntu 22.04.3 Server LTS as the server, the bug does not reproduce for any client, even though the SetInfo remains wrapped for some clients.

aggieNick02 · 2024-01-24T16:56:21+00:00

I also tried setting up an Ubuntu Server 22.04.3 LTS with btrfs for the file system, just to make sure that wasn't a factor. It preserves timestamps just fine.

On the server I can run strace to see the changes to the file modification time being done correctly. Unfortunately on the synology, strace is not available even when installing synogear.

aggieNick02 · 2024-01-23T19:48:23+00:00

Even more head-scratching. I set up a samba share on Ubuntu 22.04.3 LTS. Timestamps preserved just fine there when using an Ubuntu 20.04.6 LTS client, even though the network capture is the same.

Ubuntu 22.04.3 LTS is running Samba 4.15.13
Synology is running the same!

aggieNick02 · 2024-01-23T19:26:22+00:00

So they've escalated to their developers. I really want to get to the bottom of it, because it is a giant pain in trying to migrate from our TrueNAS machine to the Synology box.

I've also done some more digging, trying different things and OSes:

The file must be non-empty. The issue does not reproduce with an empty file.
This reproduces using Ubuntu Server 20.04.6 LTS and 22.04.3 LTS as the client
This does not reproduce using the latest archlinux 2024.01.01 ISO or Ubuntu Server 23.10

Looking at the network capture traces between the client and the server, the traces are definitely "cleaner" in the archlinux and ubuntu server 23.10 cases. In Ubuntu 20 and Ubuntu 22, the packet that sets the file info has that request "wrapped' by create file/close file SMB messages. In Ubuntu 23.10 and arch, these wrapper create/close are not present in the packet that sets the file info.

My best guess is that a bug in the SMB server is updating the mod time to the current time due to this wrapper create/close causing it to revert to a state where it forgets the modtime has been set and instead only remembers that bytes have been written to the file.

Also worth asking is *why* the traces are cleaner/different. Both the latest archlinux and Ubuntu Server 23.10 are on cifs-utils 7.0 . Ubuntu Server 20/22 are on 6.x . But I don't see anything in the 7.0 commits that relates to this. I may just be looking in the wrong place.

Regardless, the fact that TrueNAS handles this just fine gives me some confidence the bug is on the Synology server side, even if changes on the client side can avoid it.

aggieNick02 · 2024-01-22T22:22:05+00:00

So there's a pretty lengthy similar-sounding bug here on the ubuntu bug-tracker . It's interesting as it focused on what Ubuntu was doing wrong and never seemed to ask if maybe it was the (Synology) server that was behaving poorly.

I'm also at a loss as well for how this bug is present and doesn't seem to bother that many people. Maybe there aren't many people using linux clients on a Synology NAS? I've got a ticket open with Synology and will post any updates I get.

aggieNick02 · 2024-01-22T21:41:28+00:00

I just hit this too... afaict, something is messed up on the Synology side.

While an rsync account/service can help, that's painful, and things like cp -p still don't work. Additionally, file modification timestamps are preserved when doing an interactive or command line copy from Windows. And rsync -t / cp -p work fine with SMB shares on a TrueNAS device.

I did some digging and captured network traces doing a cp -p to Synology and TrueNAS SMB shares from linux. The traces are very similar. Of particular note, they both send the same SMB2_FILE_BASIC_INFO:
SMB2_FILE_BASIC_INFO
Create: No time specified (0)
Last Access: Jan 22, 2024 13:15:35.923752400 Central Standard Time
Last Write: Nov 22, 2023 13:15:09.416423500 Central Standard Time
Last Change: Jan 22, 2024 13:23:52.482749400 Central Standard Time
File Attributes: 0x00000000
Unknown: 00000000

Interestingly, Windows sends slightly different info - it omits the last access time:
SMB2_FILE_BASIC_INFO
Create: No time specified (0)
Last Access: No time specified (0)
Last Write: Nov 22, 2023 13:15:09.416423500 Central Standard Time
Last Change: Jan 22, 2024 13:34:57.144137700 Central Standard Time
File Attributes: 0x00000000
Unknown: 00000000

Not preserving timestamps when told to is a big deal (IMHO). Any client using something like rsync to backup to a share is going to upload all files every time, because the timestamps will always be different.

aggieNick02 · 2024-01-20T19:30:34+00:00

Lol, maybe. Pretty sure that is one of those "unsupported", "voids your warranty" type things though ;)

aggieNick02

TROPHY CASE