#nfsv4 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #nfsv4, aggregated by home.social.
-
Had to setup a NFS share and realized that I haven't done so since the Solaris 8 days.
Good thing that my setup is for a trusted network.
so quickly writing a/etc/exportsand adding the correct line to the clients/etc/fstabdon't forget to add a,noautothere and done.,nobootwaitdoesn't seem to be a thing anymore.I'm not looking forward to the Kerberos fuckery
Oh and before anyone asks to get a NFS server running on Chimera Linux all you have to do is
doas apk add nfs-utils-server-dinit
doas dinitctl enable nfs-server
# write your /etc/exports file
doas exportfs -a -
Had to setup a NFS share and realized that I haven't done so since the Solaris 8 days.
Good thing that my setup is for a trusted network.
so quickly writing a/etc/exportsand adding the correct line to the clients/etc/fstabdon't forget to add a,noautothere and done.,nobootwaitdoesn't seem to be a thing anymore.I'm not looking forward to the Kerberos fuckery
Oh and before anyone asks to get a NFS server running on Chimera Linux all you have to do is
doas apk add nfs-utils-server-dinit
doas dinictl nfs-utils-server-dinit
#write your /etc/exports file
doas exportfs -a -
Had to setup a NFS share and realized that I haven't done so since the Solaris 8 days.
Good thing that my setup is for a trusted network.
so quickly writing a/etc/exportsand adding the correct line to the clients/etc/fstabdon't forget to add a,noautothere and done.,nobootwaitdoesn't seem to be a thing anymore.I'm not looking forward to the Kerberos fuckery
Oh and before anyone asks to get a NFS server running on Chimera Linux all you have to do is
doas apk add nfs-utils-server-dinit
doas dinitctl enable nfs-server
# write your /etc/exports file
doas exportfs -a -
Had to setup a NFS share and realized that I haven't done so since the Solaris 8 days.
Good thing that my setup is for a trusted network.
so quickly writing a/etc/exportsand adding the correct line to the clients/etc/fstabdon't forget to add a,noautothere and done.,nobootwaitdoesn't seem to be a thing anymore.I'm not looking forward to the Kerberos fuckery
Oh and before anyone asks to get a NFS server running on Chimera Linux all you have to do is
doas apk add nfs-utils-server-dinit
doas dinictl nfs-utils-server-dinit
#write your /etc/exports file
doas exportfs -a -
Had to setup a NFS share and realized that I haven't done so since the Solaris 8 days.
Good thing that my setup is for a trusted network.
so quickly writing a/etc/exportsand adding the correct line to the clients/etc/fstabdon't forget to add a,noautothere and done.,nobootwaitdoesn't seem to be a thing anymore.I'm not looking forward to the Kerberos fuckery
Oh and before anyone asks to get a NFS server running on Chimera Linux all you have to do is
doas apk add nfs-utils-server-dinit
doas dinitctl enable nfs-server
# write your /etc/exports file
doas exportfs -a -
I run #NFSv4 on my home network of #Debian systems. It works perfectly well.
I use #SSH to move from system to system and in the past was able to get #Kerberos to work as well between them.
So far I've never been able to get NFS and Kerberos to work at the same time and this bugs me. I will have to try harder to make it work.
I don't strictly need to make it work, all my systems are inside my firewall/NAT but it annoys me that I failed to make it work.
-
I run #NFSv4 on my home network of #Debian systems. It works perfectly well.
I use #SSH to move from system to system and in the past was able to get #Kerberos to work as well between them.
So far I've never been able to get NFS and Kerberos to work at the same time and this bugs me. I will have to try harder to make it work.
I don't strictly need to make it work, all my systems are inside my firewall/NAT but it annoys me that I failed to make it work.
-
I run #NFSv4 on my home network of #Debian systems. It works perfectly well.
I use #SSH to move from system to system and in the past was able to get #Kerberos to work as well between them.
So far I've never been able to get NFS and Kerberos to work at the same time and this bugs me. I will have to try harder to make it work.
I don't strictly need to make it work, all my systems are inside my firewall/NAT but it annoys me that I failed to make it work.
-
I run #NFSv4 on my home network of #Debian systems. It works perfectly well.
I use #SSH to move from system to system and in the past was able to get #Kerberos to work as well between them.
So far I've never been able to get NFS and Kerberos to work at the same time and this bugs me. I will have to try harder to make it work.
I don't strictly need to make it work, all my systems are inside my firewall/NAT but it annoys me that I failed to make it work.
-
NFSRODS v2.3.1 is released!
https://github.com/irods/irods_client_nfsrods/releases/tag/2.3.1
This release updates dependencies so that NFSRODS is compatible with iRODS 5.
-
#NFSv4 auto-mounting isn't working.
On one Debian 12 system the /etc/fstab stanza works and auto-mounts without a problem.
On a pair of Debian 12 & 13 systems, the same /etc/fstab stanza doesn't work when connecting to a different server but does work with the same server as the first one.
I thought that must mean the connection is a problem, but a manual issue of the mount, using the stanza in fstab command works perfectly.
-
#NFSv4 auto-mounting isn't working.
On one Debian 12 system the /etc/fstab stanza works and auto-mounts without a problem.
On a pair of Debian 12 & 13 systems, the same /etc/fstab stanza doesn't work when connecting to a different server but does work with the same server as the first one.
I thought that must mean the connection is a problem, but a manual issue of the mount, using the stanza in fstab command works perfectly.
-
#NFSv4 auto-mounting isn't working.
On one Debian 12 system the /etc/fstab stanza works and auto-mounts without a problem.
On a pair of Debian 12 & 13 systems, the same /etc/fstab stanza doesn't work when connecting to a different server but does work with the same server as the first one.
I thought that must mean the connection is a problem, but a manual issue of the mount, using the stanza in fstab command works perfectly.
-
#NFSv4 auto-mounting isn't working.
On one Debian 12 system the /etc/fstab stanza works and auto-mounts without a problem.
On a pair of Debian 12 & 13 systems, the same /etc/fstab stanza doesn't work when connecting to a different server but does work with the same server as the first one.
I thought that must mean the connection is a problem, but a manual issue of the mount, using the stanza in fstab command works perfectly.
-
Got #NFSv4 working over #Wireguard between an old #macmini and a #Lenovo box both running #Debian for a #RaspberryPi project.
Now I've set one MacMini up, I need to set the rest up and the RaspberryPis so that we can organise software on them easily.
-
Got #NFSv4 working over #Wireguard between an old #macmini and a #Lenovo box both running #Debian for a #RaspberryPi project.
Now I've set one MacMini up, I need to set the rest up and the RaspberryPis so that we can organise software on them easily.
-
Got #NFSv4 working over #Wireguard between an old #macmini and a #Lenovo box both running #Debian for a #RaspberryPi project.
Now I've set one MacMini up, I need to set the rest up and the RaspberryPis so that we can organise software on them easily.
-
Got #NFSv4 working over #Wireguard between an old #macmini and a #Lenovo box both running #Debian for a #RaspberryPi project.
Now I've set one MacMini up, I need to set the rest up and the RaspberryPis so that we can organise software on them easily.
-
📊 New #Haiku development report - May 2025!
A month focused on targeted improvements and stability:
- HaikuDepot now more user-friendly for newcomers
- Important Tracker and Terminal fixes
- Major BUrl class rework with cleaner API
- More stable #NFSv4 and #EXT4 drivers
- #Wacom #Intuos4 support addedInteresting milestone: 258 HaikuPorts commits vs 52 core system - shows growing maturity! 🚀
Full report: https://www.desktoponfire.com/haikuos/software/778/haiku-overview-of-may-2025-developments/
-
📊 New #Haiku development report - May 2025!
A month focused on targeted improvements and stability:
- HaikuDepot now more user-friendly for newcomers
- Important Tracker and Terminal fixes
- Major BUrl class rework with cleaner API
- More stable #NFSv4 and #EXT4 drivers
- #Wacom #Intuos4 support addedInteresting milestone: 258 HaikuPorts commits vs 52 core system - shows growing maturity! 🚀
Full report: https://www.desktoponfire.com/haikuos/software/778/haiku-overview-of-may-2025-developments/
-
📊 New #Haiku development report - May 2025!
A month focused on targeted improvements and stability:
- HaikuDepot now more user-friendly for newcomers
- Important Tracker and Terminal fixes
- Major BUrl class rework with cleaner API
- More stable #NFSv4 and #EXT4 drivers
- #Wacom #Intuos4 support addedInteresting milestone: 258 HaikuPorts commits vs 52 core system - shows growing maturity! 🚀
Full report: https://www.desktoponfire.com/haikuos/software/778/haiku-overview-of-may-2025-developments/
-
📊 New #Haiku development report - May 2025!
A month focused on targeted improvements and stability:
- HaikuDepot now more user-friendly for newcomers
- Important Tracker and Terminal fixes
- Major BUrl class rework with cleaner API
- More stable #NFSv4 and #EXT4 drivers
- #Wacom #Intuos4 support addedInteresting milestone: 258 HaikuPorts commits vs 52 core system - shows growing maturity! 🚀
Full report: https://www.desktoponfire.com/haikuos/software/778/haiku-overview-of-may-2025-developments/
-
📊 New #Haiku development report - May 2025!
A month focused on targeted improvements and stability:
- HaikuDepot now more user-friendly for newcomers
- Important Tracker and Terminal fixes
- Major BUrl class rework with cleaner API
- More stable #NFSv4 and #EXT4 drivers
- #Wacom #Intuos4 support addedInteresting milestone: 258 HaikuPorts commits vs 52 core system - shows growing maturity! 🚀
Full report: https://www.desktoponfire.com/haikuos/software/778/haiku-overview-of-may-2025-developments/
-
Barman woes on OVH
So, due to a cascade of Barman’s errors and corrupted backups due to running out of backup space, I had to pretty much clear out my Barman backup storage.
After resetting everything, however, I was not able to make a full backup, because Barman was not able to receive write-ahead logs from PostgreSQL.
2025-06-04 22:00:21,209 [523687] barman.cli ERROR: [Errno 5] Input/output error: '/backup/barman/pg/wals/00000001000000CD/00000001000000CD00000009.tmp'
See log file for more details.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/barman/cli.py", line 2390, in main
args.func(args)
File "/usr/lib/python3/dist-packages/barman/cli.py", line 1600, in archive_wal
server.archive_wal()
File "/usr/lib/python3/dist-packages/barman/server.py", line 2651, in archive_wal
self.backup_manager.archive_wal(verbose)
File "/usr/lib/python3/dist-packages/barman/backup.py", line 847, in archive_wal
archiver.archive(verbose)
File "/usr/lib/python3/dist-packages/barman/wal_archiver.py", line 213, in archive
self.archive_wal(compressor, wal_info)
File "/usr/lib/python3/dist-packages/barman/wal_archiver.py", line 356, in archive_wal
shutil.copystat(src_file, tmp_file)
File "/usr/lib/python3.12/shutil.py", line 388, in copystat
_copyxattr(src, dst, follow_symlinks=follow)
File "/usr/lib/python3.12/shutil.py", line 338, in _copyxattr
os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
OSError: [Errno 5] Input/output error: '/backup/barman/pg/wals/00000001000000CD/00000001000000CD00000009.tmp'Input/output error? That’s odd, but the stacktrace tells us a lot, as from the function name (
os.setxattr), we can deduce that it’s trying to set xattrs on our WAL files. The underlying storage for my backups is OVH’s Backup Storage, accessible over NFS. And NFS, for most of its life, was not able to support xattrs even if the underlying filesystem does. The support has been added to NFS 4.2, while OVH (still) uses 4.1.So, how to fix this?
Initially, I thought of downgrading Barman, because things had worked before. But that did not help, and so I had to go digging into the source code (which was painful as I am not a Python guy).
# Perform the real filesystem operation with the xlogdb lock taken. # This makes the operation atomic from the xlogdb file POV with self.server.xlogdb("a") as fxlogdb: # If the content has changed, it means the file was either compressed # or encrypted or both. In this case, we need to update its metadata if content_changed: shutil.copystat(src_file, current_file) stat = os.stat(current_file) wal_info.size = stat.st_sizeSo, if
content_changedis true, we usecopystatfromshutil.py, which copies xattrs from the original file.# If the bits of the file has changed e.g. due to compression or encryption content_changed = False # Compress the file if not already compressed if compressor and not wal_info.compression: compressor.compress(src_file, tmp_file) files_to_remove.append(current_file) current_file = tmp_file content_changed = True wal_info.compression = compressor.compression # Encrypt the file if encryption: encrypted_file = encryption.encrypt(current_file, dst_dir) files_to_remove.append(current_file) current_file = encrypted_file wal_info.encryption = encryption.NAME content_changed = TrueAh, so therein lies the rub: Barman assumes that it needs to do this if the content is either being compressed or encrypted. And it just so happens that I’ve also enabled GZIP compression so as not to run out of space again. Well, we have to deal with this the old-fashioned way (by lowering the retention policy). After disabling compression, Barman was able to make backups again.
Hope this helps someone, because it sure as fuck would’ve helped me.
#Barman #lighthearted #NFS #NFSv4 #OVH #pgsql #PostgreSQL #SelfHosting
-
Barman woes on OVH
So, due to a cascade of Barman’s errors and corrupted backups due to running out of backup space, I had to pretty much clear out my Barman backup storage.
After resetting everything, however, I was not able to make a full backup, because Barman was not able to receive write-ahead logs from PostgreSQL.
2025-06-04 22:00:21,209 [523687] barman.cli ERROR: [Errno 5] Input/output error: '/backup/barman/pg/wals/00000001000000CD/00000001000000CD00000009.tmp'
See log file for more details.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/barman/cli.py", line 2390, in main
args.func(args)
File "/usr/lib/python3/dist-packages/barman/cli.py", line 1600, in archive_wal
server.archive_wal()
File "/usr/lib/python3/dist-packages/barman/server.py", line 2651, in archive_wal
self.backup_manager.archive_wal(verbose)
File "/usr/lib/python3/dist-packages/barman/backup.py", line 847, in archive_wal
archiver.archive(verbose)
File "/usr/lib/python3/dist-packages/barman/wal_archiver.py", line 213, in archive
self.archive_wal(compressor, wal_info)
File "/usr/lib/python3/dist-packages/barman/wal_archiver.py", line 356, in archive_wal
shutil.copystat(src_file, tmp_file)
File "/usr/lib/python3.12/shutil.py", line 388, in copystat
_copyxattr(src, dst, follow_symlinks=follow)
File "/usr/lib/python3.12/shutil.py", line 338, in _copyxattr
os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
OSError: [Errno 5] Input/output error: '/backup/barman/pg/wals/00000001000000CD/00000001000000CD00000009.tmp'Input/output error? That’s odd, but the stacktrace tells us a lot, as from the function name (
os.setxattr), we can deduce that it’s trying to set xattrs on our WAL files. The underlying storage for my backups is OVH’s Backup Storage, accessible over NFS. And NFS, for most of its life, was not able to support xattrs even if the underlying filesystem does. The support has been added to NFS 4.2, while OVH (still) uses 4.1.So, how to fix this?
Initially, I thought of downgrading Barman, because things had worked before. But that did not help, and so I had to go digging into the source code (which was painful as I am not a Python guy).
# Perform the real filesystem operation with the xlogdb lock taken. # This makes the operation atomic from the xlogdb file POV with self.server.xlogdb("a") as fxlogdb: # If the content has changed, it means the file was either compressed # or encrypted or both. In this case, we need to update its metadata if content_changed: shutil.copystat(src_file, current_file) stat = os.stat(current_file) wal_info.size = stat.st_sizeSo, if
content_changedis true, we usecopystatfromshutil.py, which copies xattrs from the original file.# If the bits of the file has changed e.g. due to compression or encryption content_changed = False # Compress the file if not already compressed if compressor and not wal_info.compression: compressor.compress(src_file, tmp_file) files_to_remove.append(current_file) current_file = tmp_file content_changed = True wal_info.compression = compressor.compression # Encrypt the file if encryption: encrypted_file = encryption.encrypt(current_file, dst_dir) files_to_remove.append(current_file) current_file = encrypted_file wal_info.encryption = encryption.NAME content_changed = TrueAh, so therein lies the rub: Barman assumes that it needs to do this if the content is either being compressed or encrypted. And it just so happens that I’ve also enabled GZIP compression so as not to run out of space again. Well, we have to deal with this the old-fashioned way (by lowering the retention policy). After disabling compression, Barman was able to make backups again.
Hope this helps someone, because it sure as fuck would’ve helped me.
#Barman #lighthearted #NFS #NFSv4 #OVH #pgsql #PostgreSQL #SelfHosting
-
Barman woes on OVH
So, due to a cascade of Barman’s errors and corrupted backups due to running out of backup space, I had to pretty much clear out my Barman backup storage.
After resetting everything, however, I was not able to make a full backup, because Barman was not able to receive write-ahead logs from PostgreSQL.
2025-06-04 22:00:21,209 [523687] barman.cli ERROR: [Errno 5] Input/output error: '/backup/barman/pg/wals/00000001000000CD/00000001000000CD00000009.tmp'
See log file for more details.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/barman/cli.py", line 2390, in main
args.func(args)
File "/usr/lib/python3/dist-packages/barman/cli.py", line 1600, in archive_wal
server.archive_wal()
File "/usr/lib/python3/dist-packages/barman/server.py", line 2651, in archive_wal
self.backup_manager.archive_wal(verbose)
File "/usr/lib/python3/dist-packages/barman/backup.py", line 847, in archive_wal
archiver.archive(verbose)
File "/usr/lib/python3/dist-packages/barman/wal_archiver.py", line 213, in archive
self.archive_wal(compressor, wal_info)
File "/usr/lib/python3/dist-packages/barman/wal_archiver.py", line 356, in archive_wal
shutil.copystat(src_file, tmp_file)
File "/usr/lib/python3.12/shutil.py", line 388, in copystat
_copyxattr(src, dst, follow_symlinks=follow)
File "/usr/lib/python3.12/shutil.py", line 338, in _copyxattr
os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
OSError: [Errno 5] Input/output error: '/backup/barman/pg/wals/00000001000000CD/00000001000000CD00000009.tmp'Input/output error? That’s odd, but the stacktrace tells us a lot, as from the function name (
os.setxattr), we can deduce that it’s trying to set xattrs on our WAL files. The underlying storage for my backups is OVH’s Backup Storage, accessible over NFS. And NFS, for most of its life, was not able to support xattrs even if the underlying filesystem does. The support has been added to NFS 4.2, while OVH (still) uses 4.1.So, how to fix this?
Initially, I thought of downgrading Barman, because things had worked before. But that did not help, and so I had to go digging into the source code (which was painful as I am not a Python guy).
# Perform the real filesystem operation with the xlogdb lock taken. # This makes the operation atomic from the xlogdb file POV with self.server.xlogdb("a") as fxlogdb: # If the content has changed, it means the file was either compressed # or encrypted or both. In this case, we need to update its metadata if content_changed: shutil.copystat(src_file, current_file) stat = os.stat(current_file) wal_info.size = stat.st_sizeSo, if
content_changedis true, we usecopystatfromshutil.py, which copies xattrs from the original file.# If the bits of the file has changed e.g. due to compression or encryption content_changed = False # Compress the file if not already compressed if compressor and not wal_info.compression: compressor.compress(src_file, tmp_file) files_to_remove.append(current_file) current_file = tmp_file content_changed = True wal_info.compression = compressor.compression # Encrypt the file if encryption: encrypted_file = encryption.encrypt(current_file, dst_dir) files_to_remove.append(current_file) current_file = encrypted_file wal_info.encryption = encryption.NAME content_changed = TrueAh, so therein lies the rub: Barman assumes that it needs to do this if the content is either being compressed or encrypted. And it just so happens that I’ve also enabled GZIP compression so as not to run out of space again. Well, we have to deal with this the old-fashioned way (by lowering the retention policy). After disabling compression, Barman was able to make backups again.
Hope this helps someone, because it sure as fuck would’ve helped me.
#Barman #lighthearted #NFS #NFSv4 #OVH #pgsql #PostgreSQL #SelfHosting
-
Been set a challenge to make #Synology #NAS which doesn't have #Wireguard on, accessible over the Internet.
I think I'm going to use a #Debian VM in the cloud as my public Wireguard entry point and a Debian box inside the office to act as my relay, and then use IP tables rules to relay packets to and from the Synology NAS. I think it can all be done.
-
Been set a challenge to make #Synology #NAS which doesn't have #Wireguard on, accessible over the Internet.
I think I'm going to use a #Debian VM in the cloud as my public Wireguard entry point and a Debian box inside the office to act as my relay, and then use IP tables rules to relay packets to and from the Synology NAS. I think it can all be done.
-
Been set a challenge to make #Synology #NAS which doesn't have #Wireguard on, accessible over the Internet.
I think I'm going to use a #Debian VM in the cloud as my public Wireguard entry point and a Debian box inside the office to act as my relay, and then use IP tables rules to relay packets to and from the Synology NAS. I think it can all be done.
-
Been set a challenge to make #Synology #NAS which doesn't have #Wireguard on, accessible over the Internet.
I think I'm going to use a #Debian VM in the cloud as my public Wireguard entry point and a Debian box inside the office to act as my relay, and then use IP tables rules to relay packets to and from the Synology NAS. I think it can all be done.
-
Been set a challenge to make #Synology #NAS which doesn't have #Wireguard on, accessible over the Internet.
I think I'm going to use a #Debian VM in the cloud as my public Wireguard entry point and a Debian box inside the office to act as my relay, and then use IP tables rules to relay packets to and from the Synology NAS. I think it can all be done.
-
@le_friwi_56 I use Strawberry on a small PC next to my old Pioneer A-400X amp, driving old Mission 760SE speakers. The AV kit is over 30 years old and while good for it's price in it's day, it was never the best possible. But it works.
I have all my music ripped to #FLAC and then available via #NFSv4 to any computer in the house, and also via a #DLNA server.
-
@le_friwi_56 I use Strawberry on a small PC next to my old Pioneer A-400X amp, driving old Mission 760SE speakers. The AV kit is over 30 years old and while good for it's price in it's day, it was never the best possible. But it works.
I have all my music ripped to #FLAC and then available via #NFSv4 to any computer in the house, and also via a #DLNA server.
-
@le_friwi_56 I use Strawberry on a small PC next to my old Pioneer A-400X amp, driving old Mission 760SE speakers. The AV kit is over 30 years old and while good for it's price in it's day, it was never the best possible. But it works.
I have all my music ripped to #FLAC and then available via #NFSv4 to any computer in the house, and also via a #DLNA server.
-
@le_friwi_56 I use Strawberry on a small PC next to my old Pioneer A-400X amp, driving old Mission 760SE speakers. The AV kit is over 30 years old and while good for it's price in it's day, it was never the best possible. But it works.
I have all my music ripped to #FLAC and then available via #NFSv4 to any computer in the house, and also via a #DLNA server.
-
Anyone have experience running an #NFSv4 server on #Kubernetes?
I'm not finding anything recent: a four-year-old Docker image, a six-year-old blog post,…
-
Anyone have experience running an #NFSv4 server on #Kubernetes?
I'm not finding anything recent: a four-year-old Docker image, a six-year-old blog post,…
