This is not correct. I also thought the same thing as you years ago but that's not the case.
Interesting. It is still such a common easy to find suggestion, and I had to work a little harder to find the downsides. Oh well, sudo docker it is going forward.
An even "looser" suggestion was previously made, but either not read or read and ignored.
It is also possible to set UMASK within the NZBget application in Settings | Security.
Sure, but there will be some trouble. When I commented out UMask=002 in the compose file and set UMask=002 in NZBGet, the downloaded file did indeed have 0664 permissions for read and write, but the parent folder permissions were 2755, which prevented the downloaded file from being renamed or deleted by users in the same group. Writing UMask=002 to the compose file with parent folder permission 2775 can avoid this issue.
Sure, but there will be some trouble. When I commented out UMask=002 in the compose file and set UMask=002 in NZBGet, the downloaded file did indeed have 0664 permissions for read and write, but the parent folder permissions were 2755, which prevented the downloaded file from being renamed or deleted by users in the same group. Writing UMask=002 to the compose file with parent folder permission 2775 can avoid this issue.
Hai Zafkiel, can you tell me more about 2775?
I noticed indeed. I can remove the file now with winSCP. but indeed not throught the SMB
Ron
Hai Zafkiel, can you tell me more about 2775?
I noticed indeed. I can remove the file now with winSCP. but indeed not throught the SMB
Ron
Ummm, I always first down NZBGet and then delete the config and downloads folders created by NZBGet before testing, which can avoid some permission issues not being reflected.
Supplement: If you also deleted the shared folder created by OMV during testing, there might be permission issues as well. In short, you only need to delete the folder created by NZBGet.
Hmm. been there almost, if I look on the winSCP the directory is on mine name.
I can removed the file in winSCP but not on SMB.
The solution from ChatGPT - drwxrwsr-x 2 usergroup 4096 date time /data/nzbget/data is be done. but still not be able te remove the file via Smb.
Have also renew the SMB config, but still not be able.
permissies correct
drwxrwsr-x 2 ron users 4096 31 okt 16:38 /data/nzbget/data
Its complicated for me, looks not so simple to get its working ..
drwxrwsr-x 2 ron users 4096 31 okt 16:38 /data/nzbget/data
May I ask which shared folder you created with OMV? Which one was created by NZBGet?
SMB has its own weirdness about permissions. There are ways to control the permissions on shared folders via OMV environment variables and optional settings in the share creation box in the GUI but I have no idea what they are as I do not use SMB or have any Windows machines here.
Good luck
May I ask which shared folder you created with OMV? Which one was created by NZBGet?
Nas is created with OMV and the nzbget is created by NZBget.
SMB has its own weirdness about permissions. There are ways to control the permissions on shared folders via OMV environment variables and optional settings in the share creation box in the GUI but I have no idea what they are as I do not use SMB or have any Windows machines here.
Good luck
Thanks. But there must be others users are using it. Think I am not the only person with this.
I want to understand why it's not working.
On synology was it not a issue, but than nzbget was not created on docker.
So is it a issue of OMV of de the image.
Before I go further I want to have it works.
Ron
Nas is created with OMV and the nzbget is created by NZBget.
Can you show me screenshots of your OMV's Storage > Shared Folders, Services > SMB/CIFS > Shares, User Management > Users, the NZBGet compose file code, and the code from OMV's Diagnostics > Services > SMB/CIFS? Like this:
services:
nzbget:
image: lscr.io/linuxserver/nzbget:latest
container_name: nzbget
environment:
- PUID=1001
- PGID=100
- TZ=Asia/Shanghai
- NZBGET_USER=test
- NZBGET_PASS=test
- UMASK=0002
volumes:
- /test-nzbget/config:/config
- /test-nzbget/downloads:/downloads
ports:
- 6789:6789
restart: unless-stoppedPID Username Group Machine Protocol Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
1180299 Fan users 192.168.1.2 (ipv4:192.168.1.2:49757) SMB3_11 - partial(AES-128-CMAC)
Service pid Machine Connected at Encryption Signing
---------------------------------------------------------------------------------------------
影视 1180299 192.168.1.2 Fri Nov 1 18:12:53 2024 CST - -
Locked files:
Pid User(ID) DenyMode Access R/W Oplock SharePath Name Time
--------------------------------------------------------------------------------------------------
1180299 1000 DENY_NONE 0x100080 RDONLY NONE /SSD/影视 . Fri Nov 1 18:17:25 2024Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!